Supabase

Postgres-based platform: database, auth, storage, edge functions, realtime, vectors. Open source.

VISIT SUPABASE

Key takeaway: Reach for Supabase when Postgres is the right data shape and you would rather not assemble auth, file storage, and realtime yourself. It is the wrong pick if you only want a database, because you will pay attention to a platform you never call. Neon is the cleaner choice in that case; Supabase wins when the bundle is the point.

Quick facts

  • CategoryPostgres
  • EnginePostgres
  • PricingFreemium
  • LicenseApache-2.0
  • Created2020
  • GitHub stars86.4k
  • PostgresCompatible
  • Edge-readyNo

Bundled features: Auth Storage Edge Functions Realtime Vector (pgvector)

What it is

Supabase is the open-source Firebase alternative built around Postgres. Database with auto-generated REST + GraphQL APIs, auth, storage, edge functions, realtime subscriptions, pgvector for embeddings. The default for full-stack JS apps that want owned-data and Postgres ergonomics.

Best for

  • Full-stack apps that need database + auth + storage + functions in one platform
  • Postgres + RLS workloads where row-level security is the primary access control
  • Vector search + RAG apps using pgvector inside the same database
  • Migrating off Firebase to a Postgres-shape data model

When not to pick it

Skip Supabase for very high-write, low-latency workloads where Postgres is the wrong shape, pick Cloudflare D1 / Turso for edge or MongoDB Atlas for document-heavy data.

My take

Supabase is the default platform for most full-stack JS / TS apps in 2026. The trade-off is the platform pull, once you adopt Supabase, you tend to use Supabase Auth, Storage, Edge Functions, etc. That is fine if you want Postgres at the centre.

Postgres does the work, the platform does the wiring

The thing to understand is that Supabase is not an abstraction over Postgres, it is Postgres with scaffolding bolted on. Your tables are real tables, your indexes are real indexes, psql connects to it, and every ORM in the ecosystem already speaks to it. What Supabase adds is the tedious half: REST and GraphQL APIs generated from your schema, sessions and OAuth handled for you, storage buckets governed by the same row-level rules as your tables, and pgvector sitting there as an extension you switch on. Row-level security is the load-bearing idea. Access control lives in the database as policies rather than in application middleware, so a leaked anon key is not automatically a leaked database. It also means access-control bugs are database bugs, and debugging a policy that silently returns zero rows is genuinely unpleasant the first few times. Budget real learning time before you ship anything holding user data.

Platform pull, and how hard the exit actually is

Supabase is Apache-2.0 and self-hostable, and the data is ordinary Postgres, so a dump gets you out whenever you want. That is more than most of this category can say. The stickiness is not the database, it is everything around it. Once your app calls Supabase Auth, reads from storage buckets, and runs Edge Functions, leaving means reimplementing three services rather than one. Self-hosting the full stack is also a much larger job than running Postgres, since you are operating a set of coordinated services rather than a single engine. The other thing to plan for on day one is connections: serverless functions open them faster than Postgres likes, so use the pooler endpoint from the start instead of finding the ceiling under load. Treat that as a setup step, not an optimisation you get to later.

Frequently asked questions

Is Supabase free?

There is a free tier that covers prototypes and small projects, with paid tiers scaling by compute, storage, and bandwidth. Supabase is also Apache-2.0, so you can self-host the whole stack and pay only for servers. Most teams start hosted and only look at self-hosting when data residency or cost at scale forces the question.

Supabase or Firebase?

Supabase if your data is relational and you want SQL plus a real exit path. Firestore if you are already on the Firebase platform or shipping a mobile app where the client SDK and offline sync do most of the work. Data shape decides it: relational data in a document store fights you for the life of the project.

Does Supabase work with Next.js?

Yes, it is the most common pairing in this category. The SSR helpers handle cookie-based sessions across server components, route handlers, and middleware. Two things to get right: validate the user server-side with getUser() rather than trusting getSession(), and point serverless functions at the connection pooler instead of the direct database URL.

Links

Compare Supabase side-by-side

Supabase vs Neon → Supabase vs Firebase Firestore → Supabase vs PlanetScale → Supabase vs Convex → Supabase vs Xata → Supabase vs CockroachDB →

Similar tools you should also consider

Neon

Serverless Postgres with branching, scale-to-zero, and a deep separation of compute and storage.

Read the take →

Xata

Serverless Postgres with a higher-level data model layer. Search, file attachments, branching included.

Read the take →

Firebase Firestore

Google's document database with real-time sync and tight Firebase-platform integration.

Read the take →

If Supabase is your pick, the next conversation is short

The 30-min call is where your database choice becomes a real architecture, a migration plan if you are switching, and a price range you can take to your stakeholders. Describe your stack, your scale, your data shape. I tell you whether Supabase is genuinely your fit.