February 10, 2026 · 6 min read

Supabase as a CMS: how we run content without a CMS

Why we ditched Sanity, WordPress, and everything else for a Postgres database and Claude.

TechnicalStackSupabase

We don't use a CMS. No Sanity, no Contentful, no WordPress, no Strapi. Our content lives in Supabase — a Postgres database with a REST API — and we manage it through Claude via MCP connections.

This sounds insane. It works better than anything else we've tried.

Why traditional CMS didn't work

For the kind of sites we build — Next.js on Vercel, heavily customized, with AI integrations throughout — a traditional CMS creates more problems than it solves. Sanity has a great studio UI, but it's another service to maintain, another build step, another thing that can break. WordPress is a universe of its own that doesn't play well with modern frontends. Contentful and Prismic charge per seat and add complexity for what's ultimately just structured JSON.

We needed something that stores structured content, has a fast API, handles images and media, integrates with everything else we use, and costs almost nothing.

Supabase is all of those things. It's Postgres with auth, storage, real-time subscriptions, and edge functions. We were already using it for application data. Why add another tool?

The setup

Two tables do most of the work: page_content for structured page data (JSON columns keyed by page slug) and blog_posts for articles (title, slug, body HTML, tags, meta, dates). Images go in Supabase Storage.

The Next.js site fetches from these tables at build time using the Supabase JS client. When we update content, we trigger a Vercel deploy hook and the site rebuilds with fresh data. ISR handles the gap between deploys.

Claude as the content manager

Here's where it gets interesting. We built a Supabase edge function that exposes content operations as an MCP (Model Context Protocol) server. That means Claude — right here in the chat interface — can read, create, update, and manage all our content directly.

I can say "update the homepage hero headline" and Claude calls the MCP tool. I can say "write a blog post about AI voice design" and Claude writes it, formats the HTML, sets the metadata, and publishes it — all through tool calls. No admin panel. No WYSIWYG editor. The AI is the editor.

This isn't theoretical. This is how we manage content for multiple sites right now. The same pattern runs our own site, our client portal, and a client's marketing site.

What we gave up

There's no visual editor. Non-technical team members can't drag and drop content blocks. There's no preview button that shows exactly how a change will look before publishing.

For a two-person studio, that's fine. We're the only ones editing. And the speed advantage is enormous — updating content through a chat interface is faster than any admin panel.

For a client who needs to self-manage content, this isn't the right pattern. We'd build them something appropriate. But for our own infrastructure, Supabase + Claude is the fastest, cheapest, most flexible content management system we've ever used.

The stack, specifically

Supabase (Postgres + Storage + Edge Functions) → MCP server (edge function) → Claude (via MCP connection) → Vercel deploy hook (on content update) → Next.js (SSG/ISR, fetches from Supabase at build). Total cost: Supabase free tier + Vercel free tier. CMS cost: $0.


Keep reading
← All insightsStart a conversation →