Choosing a CMS for a Next.js marketing site: headless vs. database-backed

Pick a database, such as Supabase, when a developer owns every publish and the site stays a handful of pages. Pick a headless CMS when editors need to publish without a developer, or when the same content has to reach more than one channel. As of the Next.js documentation's June 2026 update, both approaches end up served the same way in production, as prerendered pages that revalidate on a timer. The real difference is who edits content and how, not raw speed.

What it is and why it matters

A headless CMS is a backend-only platform. It stores, models and manages content, then delivers it through a REST or GraphQL API instead of rendering its own frontend, as Vercel's overview describes it. A Next.js site consumes that API at build time or request time and renders the page. The CMS ships its own editor interface, its own permissions model and its own content types, separate from the codebase.

Database-backed content skips that separate system. The content lives in the same Postgres database the rest of the application already uses, commonly Supabase, and a Next.js Server Component queries it directly with the standard client library. No second vendor, no API layer to maintain beyond the database's own generated endpoints.

The choice matters early because switching later means rewriting the content-fetch layer and retraining whoever publishes. A headless CMS earns its cost when content needs to reach a mobile app, a partner site or a kiosk alongside the marketing pages, since the same structured content serves every channel without duplication. It earns that cost back a second way too: the moment a non-technical marketing hire needs to publish a page without opening a pull request. Vercel's own guide to choosing one frames the decision around editorial workflow, content modeling needs and publishing volume, not around framework compatibility, since both models work fine with Next.js.

How it works in practice

Caching and freshness

Neither model changes how Next.js caches a page. Setting export const revalidate = 3600 on a route tells Next.js to serve the cached version for up to an hour, then regenerate it in the background on the next request, with no downtime for the visitor in between, per the Next.js Incremental Static Regeneration guide. For a direct database query rather than a fetch call, the same guide recommends wrapping the query in unstable_cache with a revalidate interval and cache tags, so a Supabase-backed page gets identical stale-while-revalidate behavior to a CMS-backed one. How that caching mechanism works end to end covers the revalidate window and background regeneration in more detail.

Publishing a change

With a headless CMS, an editor saves a change and the CMS fires a webhook that calls revalidatePath or revalidateTag, updating the cached page on the next request. With a database-backed site, a Server Action writes the row directly and calls that same function itself, no webhook hop required. The invalidation work is equivalent either way; a headless CMS just adds a network round trip between the save and the revalidation.

Access control

A headless CMS ships its own editor roles and content permissions out of the box. A database-backed site relies on Row Level Security policies at the Postgres level to do the same job, restricting which rows a given key or authenticated user can read or write. Both are real access control. The difference is whether that control lives in a vendor's admin panel or in policies the team writes and owns.

Tradeoffs and edge cases

Cost

Headless CMS platforms carry a recurring bill. Pricing runs from roughly 99 USD a month at the low end to around 300 USD a month for enterprise-leaning platforms, or a per-seat model near 15 USD a seat per month, according to Vercel's headless CMS comparison. A database-backed site avoids that line item, but if editors need a friendly way to publish, someone still has to build and maintain a lightweight admin UI on top of the database. That's its own ongoing cost, just a different one.

Editorial independence versus developer ownership

Most of the marketing sites Kallos Labs ships are a handful of pages, maintained by the same team that built them. For that shape of site, a headless CMS is overhead the project hasn't earned back yet, since the developer publishing the content is already in the codebase. The calculation flips the moment a marketing lead needs to change copy, add a page or run a campaign without waiting on engineering time.

Multi-channel reuse

If the same article, product description or FAQ needs to reach a native app or a partner's site in addition to the marketing pages, a headless CMS's structured content avoids maintaining that copy in two or three places. A database table scoped to one site's schema doesn't generalize the same way without extra work.

Technical constraints either way

Incremental Static Regeneration requires the Node.js runtime and is not supported with a static export, a constraint the Next.js documentation states plainly, so hosting choice matters regardless of which content model is picked. A technical SEO audit checklist for Next.js sites covers the caching and indexing issues that show up under either approach. When a client asks Kallos Labs which one fits, the answer comes out of discovery, specifically who will publish and how often, not a default tool choice. The web development engagement scopes that decision before any code gets written.

Frequently asked questions

Is a headless CMS faster than a database-backed Next.js site?

Not by default. Both models end up as static or ISR-cached pages served from the same CDN, so speed comes from the caching strategy and the revalidate interval, not from which system stores the content.

Can a marketing team edit content without a headless CMS?

Yes, if there is an admin UI or a lightweight internal tool in front of the database. Without one, every content change goes through a developer, which is the real cost of skipping a CMS.

Does Supabase count as a headless CMS?

No. Supabase is a hosted Postgres database with Row Level Security and auto-generated APIs, not a content-modeling or editorial layer. A team can build a thin admin UI on top of it, but that UI is custom work the team owns and maintains.

When does it make sense to migrate from a database-backed blog to a headless CMS?

It makes sense once non-technical editors need direct publishing access, once the same content needs to reach a second channel, or once the content model outgrows a handful of tables and needs versioning, previews and localization workflows a CMS already ships.

Conclusion

The decision comes down to who publishes and how many channels the content serves. A developer-owned site with a handful of pages runs fine on a database and Next.js ISR alone. A site where editors need independence, or where content has to reach more than the marketing pages, earns back a headless CMS's cost. Either way, the same caching layer keeps pages fast underneath: revalidate intervals doing the routine work, on-demand invalidation handling the rest.