Supabase

What is Supabase?

Supabase is a managed PostgreSQL database with the services most applications need wrapped around it. You get a real Postgres instance — extensions, SQL editor, migrations, backups — plus:

• A Data API. REST endpoints generated directly from your schema, so simple reads and writes need no backend code.
• Auth. Email, magic link, phone, social providers, SAML SSO, and MFA, with users stored in the same database and access enforced by Postgres row-level security.
• Storage. S3-compatible object storage with a CDN in front, for uploads and files.
• Realtime. WebSocket subscriptions to database changes, broadcast messaging, and presence.
• Edge Functions. Deno functions deployed globally for webhooks, third-party integrations, and server-side work that shouldn’t sit in the client.
• Vectors, queues, and cron. pgvector for embeddings and semantic search, plus background jobs and scheduling, all inside the same database.

It’s frequently described as an open-source Firebase alternative, and it is open source and self-hostable. But the more useful framing for anyone planning a long-lived web estate is simpler: it’s Postgres. Your data sits in the most portable, best-understood relational database there is, with a convenience layer on top. If Supabase ever stops being the right vendor, a Postgres dump is a genuine exit — which is not something you can say about most backend-as-a-service products.

Where it fits in the estates we build

Most of our work is content platforms: a headless CMS, a component library, a front end, and a migration to get there. Supabase shows up for the parts of those estates that aren’t content.

• Records the CMS shouldn’t hold. Gated-content requests, event and webinar registrations, product configurators, ROI and pricing calculators, saved lists, partner or dealer directories with user-submitted data. Marketers own the page in the CMS; the submitted records belong in a database.
• Customer-facing accounts. Client portals, partner areas, and logged-in resource libraries. Your workforce identity provider — Okta, Entra — governs employees; it rarely governs the public. Supabase Auth with row-level security is a defensible way to run visitor identity without building it.
• Product and internal tools around the site. Dashboards, review queues, campaign tooling. The things a marketing organisation asks for after launch, which need to be real software but don’t justify a platform programme.
• Search and AI features that need relational context. pgvector next to your actual tables means one query can filter on permissions, market, and locale and rank by similarity — without a second vector service to sync and secure.

It sits comfortably behind whatever the front end runs on. We wire it into estates deployed to Vercel, Netlify, Cloudflare, and to clients’ own cloud accounts.

Where it doesn’t

It is not a CMS. The temptation on every project is to model editorial content as Postgres tables because the database is already there, then hand editors a table GUI. That’s where the whole point of a headless platform quietly dies: no editorial workflow, no versioning, no preview, no localisation model, no publishing autonomy. Content goes in the CMS. Records go in Supabase. Keeping that line clean is one of the more consequential architecture decisions on a build.

It is not the system of record. Leads belong in the CRM, product data in the PIM, transactions in the commerce platform. Supabase is the operational store for the site’s own application logic, and it should sync with those systems rather than compete with them. When a database on the website becomes a shadow CRM, someone spends the next two years reconciling it.

It isn’t automatically the right Postgres. If the organisation already runs managed Postgres under an AWS, Azure, or GCP commitment, with a data team and backup and access policies that already pass review, adding a vendor to get a nicer dashboard is a poor trade. If all you need is the database — no auth, no storage, no realtime — a pure serverless Postgres like Neon is a lighter dependency. We recommend Supabase when the bundle earns its place, not by default.

When to use it — and when not to

Use Supabase when	Use something else when
The site needs real application data — accounts, submissions, tools — alongside CMS content	It's editorial content: pages, articles, campaigns, localised copy. That's the CMS.
You want auth, storage, and an API without assembling and operating four services	You already run managed Postgres under an existing cloud contract, with a team that owns it
Postgres portability matters: you want a database you could take elsewhere	The data belongs in the CRM, PIM, or commerce platform — integrate, don't duplicate
A small build needs to be production-grade quickly, with RLS doing the access control	Compliance requires the data inside your own tenancy and Supabase's regions or BYO-cloud terms don't cover it

Governance, in plain terms

The questions a security review will ask, answered honestly. Supabase carries SOC 2 Type II and ISO 27001 on its Team plan and above, with a HIPAA option and enterprise agreements covering BYO-cloud arrangements; data is encrypted at rest and in transit; region choice includes the EU. Point-in-time recovery, read replicas, log drains, and audit logs sit on the paid tiers, and dashboard access can be put behind SSO.

The control that actually decides whether this passes review is row-level security. Because the Data API is generated from your schema, an unprotected table is a published table. RLS policies are the authorisation layer, they need designing and testing like any other security control, and they need to be re-tested when the schema changes. Misconfigured policies — not platform failure — are the common thread in the Supabase data exposures that get reported publicly.

Pricing, in plain terms

Plans are billed per organisation — a free tier, then Pro, Team, and Enterprise — while compute is billed per project instance, with a small credit included on paid plans. Storage, egress, monthly active users, and add-ons like point-in-time recovery are metered on top.

The growth-cost driver that surprises people isn’t traffic — it’s project count. Every project carries its own compute line, so a multi-brand estate that spins up a project per brand, plus staging and long-lived preview environments, is paying for instances rather than usage. Decide the project topology early: one database with schema separation and RLS is usually cheaper and easier to govern than a project per site. Current rates are on Supabase’s pricing page.

The Bejamas take

We integrate Supabase; we don’t build estates around it. On a content platform the centre of gravity is the CMS and the design system — the database is the thing that holds what the CMS shouldn’t. Used that way it’s excellent: fast to stand up, cheap to run, and backed by a database your team could operate anywhere if the relationship ever ends. Used as the centre of the stack, it slowly turns into a bespoke CMS with no editorial workflow, and marketers end up filing tickets again. In an audit we map which data belongs in your CMS, which belongs in your existing systems of record, and which needs a database of its own — and we tell you when that database should be your cloud’s rather than a new vendor’s.