decoupled.io
← All Articles
Comparisons

Supabase Is Not Your CMS for Lovable and Bolt.new Apps

Jay Callicott··8 min read

Supabase Is Not Your CMS for Lovable and Bolt.new Apps

If you build with Lovable, Bolt.new, or v0, the current trend is obvious: AI app builders are moving beyond mockups and into full-stack app generation.

On February 3, 2026, Vercel introduced the new v0 as a platform for "production apps and agents." Lovable's docs now center heavily on chat-driven Supabase setup, auth, secrets, and payments. Bolt's current docs go even further: new Claude Agent projects default to Bolt Database, with Supabase as an optional alternative.

That shift is useful, but it also creates a common architecture mistake.

Teams start treating the database as the content system.

That works for user accounts, orders, messages, feature flags, and app state. It breaks down when marketing needs to update a homepage, launch a campaign page, edit pricing blocks, reuse testimonials, or preview a landing page before publishing.

If you are searching for a headless CMS for Lovable, a bolt.new CMS, or a better lovable backend for content-heavy apps, this is the distinction that matters: a database is not a CMS.

Why this question is showing up now

The tooling changed fast over the last few months:

  • Lovable added more full-stack workflows around Supabase, payments, and environment handling.
  • Bolt normalized database provisioning inside the builder itself.
  • v0 repositioned around production codebases, PRs, and real shipping workflows.
  • MCP continued maturing toward more production-ready transports and agent tooling.

That combination means AI builders can now generate more of the stack for you. But the more capable they get, the more clearly teams hit the next bottleneck: content operations.

Developers usually notice it as code smell:

  • copy embedded in JSX
  • pricing tables stored in JSON files
  • hero sections hardcoded into route components
  • campaign pages cloned from old pages instead of modeled cleanly

Marketers notice the same problem from the other side:

  • every edit needs a developer
  • no draft and publish flow
  • no visual page editing
  • no reusable content blocks across channels
  • no safe way to let AI assist with content without writing into source code

That is not a database problem. It is a CMS problem.

What Supabase and Bolt databases are actually good at

This is the part worth being precise about. Supabase is excellent at what it is built for:

  • relational application data
  • authentication and user management
  • file storage
  • realtime features
  • edge functions and backend logic
  • SQL-level control over your data model

Bolt Database aims at a similar category of needs, just with more of the setup hidden behind the builder UX.

For AI-built apps, that is a strong fit for:

  • user profiles
  • subscriptions
  • shopping carts
  • app settings
  • internal dashboards
  • workflow state
  • AI-generated records and logs

If your "content" is really just application data, a database may be enough.

The problem is that most public-facing products have another class of data that behaves differently: editorial content.

Editorial content needs schema, yes, but it also needs workflow, preview, versioning, media management, permissions, page composition, and often non-developer editing.

That is why trying to use database tables as a CMS usually turns into custom admin screens, hand-rolled preview logic, and a lot of duplicated effort.

What a CMS adds that a database does not

A proper headless CMS gives you features that are expensive to recreate ad hoc:

  • structured content types for pages, authors, FAQs, promos, and reusable sections
  • editorial roles and permissions
  • drafts, revisions, and publishing workflows
  • media handling for images, documents, and embeds
  • stable delivery APIs such as GraphQL and JSON:API
  • visual editing for marketers who should not be in your codebase

This matters even more now that Drupal's decoupled tooling is improving. The Drupal GraphQL project shipped 5.0.0-beta2 on February 19, 2026, and GraphQL Compose's 3.x line is explicitly targeting GraphQL 5 support. At the same time, GraphQL Compose Mutations reached a stable 1.0 release in January 2026, which is useful for more agent-driven and form-driven workflows.

The practical takeaway is not "replace your database with Drupal." It is the opposite: keep each system responsible for the kind of data it handles best.

The architecture that usually works best

For most AI-built apps, the clean production pattern looks like this:

  • Use Lovable, Bolt.new, or v0 to generate the frontend and app logic.
  • Use Supabase or Bolt Database for user data and transactional state.
  • Use a headless CMS for editorial content, pages, media, and marketing operations.
  • Use MCP to let agents provision and update that CMS safely.

That split keeps your codebase cleaner and your handoff to marketers much simpler.

// app/lib/content.ts
const PAGE_QUERY = `
  query LandingPage($path: String!) {
    route(path: $path) {
      ... on NodeLandingPage {
        title
        heroHeadline
        heroSubhead
        ctaText
      }
    }
  }
`

export async function getLandingPage(path = "/") {
  const res = await fetch(process.env.DRUPAL_GRAPHQL_URL!, {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      Authorization: `Bearer ${process.env.DRUPAL_TOKEN!}`,
    },
    body: JSON.stringify({
      query: PAGE_QUERY,
      variables: { path },
    }),
    next: { revalidate: 60 },
  })

  const { data } = await res.json()
  return data.route
}

// app/lib/account.ts
import { createClient } from "@supabase/supabase-js"

const supabase = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!
)

export async function getCurrentUserProfile() {
  const {
    data: { user },
  } = await supabase.auth.getUser()

  if (!user) return null

  const { data } = await supabase
    .from("profiles")
    .select("*")
    .eq("id", user.id)
    .single()

  return data
}

That separation is boring in the right way. Content comes from the CMS. Application state comes from the database. Your frontend stays easy to reason about.

When a database-only approach is still fine

You do not need a CMS on day one for every project.

A database-only setup is usually fine if:

  • the app is internal
  • only developers edit the content
  • pages are few and rarely change
  • there is no marketing team involved
  • there is no need for preview, scheduling, or reusable page sections

But the threshold for "we need a CMS now" arrives earlier than many AI builder teams expect. A few signs:

  • your homepage copy changes often
  • you need campaign or landing pages
  • non-developers need access
  • you want a visual editor instead of editing SQL rows or JSON
  • your content must feed web, email, app, and AI workflows from one source

That is where a managed decoupled Drupal setup becomes attractive. Decoupled.io gives you Drupal as a headless CMS with GraphQL, JSON:API, a visual page builder, and MCP tooling, so the content layer is production-ready without forcing you to abandon your AI-generated frontend.

If you want to explore that stack, the most relevant docs are the MCP tools, GraphQL API, and visual editor.

How to choose for Lovable, Bolt.new, and similar builders

If you are deciding between "just use Supabase" and "add a CMS," use this rule:

  • Choose database-only when the product is mostly app state.
  • Choose database plus CMS when the product has an active content team or public marketing surface.

In practice, many teams need both.

That is especially true for startups building with AI tools, because the frontend gets generated quickly while the content model gets deferred. The fastest way to avoid a painful rewrite later is to separate those concerns early.

Use the builder for speed. Use the database for state. Use the CMS for content.

Start with the right split

The 2026 AI builder wave is making it much easier to spin up full-stack apps. That is real progress. But it also makes architectural boundaries easier to blur.

If your team is shipping with Lovable, Bolt.new, Base44, Replit Agent, or v0, the winning move is usually not to force one tool to do everything. It is to let each layer do its job well.

If you want a headless CMS for AI apps that fits that pattern, start with getting started, review the MCP tools, and look at the GraphQL API. That gives you a cleaner backend for content without throwing away the speed of your AI builder.