Headless CMS vs a database of the site's own

The core difference

The two tools answer different questions. A headless CMS answers "how do editors change what the site says?" It gives them a friendly editing screen, drafts, previews, scheduled publishing and image handling, and the website fetches the published content through an API. "Headless" means it has no front end of its own; your site supplies the design. A database answers "how does the site remember what visitors do?" When someone books a table, joins a waitlist, places an order or posts in a community, a row is created that belongs to them, may be private, and may need to be checked against other rows, such as a booking that must not overlap another. A CMS can store a contact form message, but it is not designed for many people writing at once, for rules that say each person sees only their own rows, or for a payment status that must change exactly once.

How each one works behind a page

With a headless CMS, an editor writes a post and presses publish. The website either fetches the post when a visitor opens the page or, more often, rebuilds static pages when content changes, which keeps pages fast. Visitors only ever read. With a database, the page itself reads and writes. A booking page asks for free slots, the visitor picks one, and the site saves a booking row; the database refuses it if another booking already holds that time. Access is decided per row: anyone may read services, only the person who made a booking may read it, and only staff may confirm it. Changes that must happen together, such as taking the last ticket and creating the order, run in one transaction so neither happens without the other. An admin area, built into the site, then gives staff screens over the same tables, which is how a database site gets its own editing tools.

When a site needs which

Choose a CMS when the site is mostly content written by a team: a magazine, a large blog, a documentation site, or a marketing site where non technical editors publish daily and need approval steps. Choose a database when visitors do things: book, order, pay, sign in, save favourites, apply for a job, bid or message. Many small business sites are the second kind with only a little content, such as a menu, a services list and an about page; those fit comfortably as database rows with an admin screen, or as text in the site's code that changes a few times a year. Use both when a content heavy site also has transactions, for example a publisher with paid memberships. In that case keep a clear line: articles live in the CMS, while members, subscriptions and comments live in the database, so each tool does what it was designed for.

Common mistakes

Bending a CMS into an order system, then discovering it cannot stop two people buying the last item or keep one customer's order private from another. Adding a CMS to a site whose content changes twice a year, which adds a login, a monthly bill and an API dependency for very little. Putting content that editors need to change daily into code, so every typo fix needs a developer. Splitting one kind of data across both tools, such as products in the CMS and stock levels in the database, then fighting to keep them in step. Forgetting access rules on database tables because the CMS never needed them. And choosing based on a tool's popularity rather than on a list of what visitors and staff will actually do on the site in its first year.

Where it shows up in OneCraft

OneCraft writes every site as code: a React Router, Tailwind and shadcn/ui project in its own repository. When a requested feature needs data, such as bookings, orders or members, the AI enables a database for that site: a schema of its own in OneCraft's pool project, or a project on the owner's own Supabase account when they connect one. Hosted schemas are included on every plan, or the owner can connect their own Supabase account. Every table has row level security, checked as an anonymous visitor and as a signed in person. Staff manage rows from an admin area inside the site, shown only to people in its site admins table. There is no separate CMS, and changes to fixed page text are made by chat, each change saved as a commit in the site's version history.

Questions people ask