Both Neon and Supabase put a Postgres connection string in your hands in under a minute, both have a free tier you can ship a side project on, and both added database branching before it was fashionable. That surface similarity is exactly why developers stall on the choice. The useful question isn't "which is better" — it's "which problem are you actually solving?" One is a database. The other is a backend that happens to be built on a database.
We ran both for a small production app over several months — same schema, same query patterns — and the split is cleaner than the marketing suggests. Here's how to pick without regretting it six months in.
What you're actually choosing between
Neon is serverless Postgres, full stop. The headline feature is the separation of storage and compute: your data lives in a storage layer, and the compute that runs queries is a separate, ephemeral thing that can spin down to nothing when idle and spin back up on the next connection. That's where scale-to-zero comes from — an idle Neon database costs you storage and effectively no compute. The other standout is branching: Neon creates a copy-on-write branch of your entire database in roughly a second, so a branch is cheap even when the parent holds gigabytes. You get a Postgres endpoint and the Postgres ecosystem. You do not get auth, file storage, or an auto-generated API.
Supabase is a backend platform that wraps a normal (always-on by default) Postgres instance with the parts most apps need anyway: authentication, row-level-security-backed authorization, an auto-generated REST API via PostgREST, realtime subscriptions over websockets, object storage, and edge functions. The pitch is that you wire your frontend straight to Supabase and skip writing a backend tier. Supabase has also shipped branching, but its center of gravity is the full feature set, not the database substructure.
So the first fork is structural, not about quality:
- If you already have an API layer (Rails, Django, a Go service, Next.js route handlers) and you just need Postgres underneath it, you're shopping for a database. That's Neon's lane.
- If you want auth, storage, and a client-side data API without standing up your own backend, you're shopping for a platform. That's Supabase's lane.
Neon being "just the database" doesn't mean you give up auth or APIs — it means you bring your own. Pairing Neon with a dedicated auth provider and your own API framework is a common pattern. It's more wiring up front in exchange for not being coupled to one platform's opinions. Supabase trades that flexibility for a faster start.
Where each one wins
Neon wins on the database itself. Scale-to-zero is genuinely useful for the long tail of projects that are idle most of the day — preview environments, internal tools, early-stage apps with bursty traffic. You pay for compute when queries actually run. The branching workflow is the other reason teams reach for Neon: spinning a branch per pull request gives every preview deploy its own isolated database that's a near-instant fork of production-shaped data, then tears down when the PR closes. If your CI already creates ephemeral environments, this slots in cleanly.
The trade-off is the cold start. When a scaled-to-zero compute has to wake, the first query after idle pays a resume latency penalty — typically sub-second, but non-zero, and noticeable on a request that would otherwise be a few milliseconds. For user-facing endpoints that must always feel instant, you either keep a minimum compute warm (which erodes the scale-to-zero savings) or accept the occasional slow first hit.
Supabase wins on time-to-app. If you're building something that needs login, user-uploaded files, and a data API today, Supabase collapses a week of backend plumbing into configuration. Row Level Security is the load-bearing piece: you express authorization as SQL policies on your tables, and both the auto-generated API and your direct queries respect them. That's powerful and also the most common place teams get burned — a missing or wrong RLS policy is a data-exposure bug, not a 500 error.
With Supabase, turning on Row Level Security and writing correct policies is on you. A table with RLS disabled and a public anon key is readable by anyone who opens devtools. Audit every table's policies before launch, and test them with an unauthenticated client — not just your admin session.
Whichever database you land on, the app you build on top of it is where most of your hours go. A capable AI-assisted editor pays for itself fastest exactly when you're writing migration scripts, RLS policies, and data-access code against an unfamiliar API.
How to decide
Strip it to three questions.
- Do you already have a backend? If yes, you want a database, and Neon's scale-to-zero plus branching is the stronger play. If no and you'd rather not build one, Supabase saves you the most time.
- What's your traffic shape? Spiky or mostly-idle workloads (preview envs, internal dashboards, side projects) are where Neon's pay-for-active-compute model is cheapest. Steady traffic that keeps a database busy erases the idle-cost advantage, which moves the decision back to features.
- How much do you care about lock-in? Neon is close to vanilla Postgres — moving off it is mostly a connection-string change plus re-hosting your own auth and API, which you already own. Supabase's value is the integrated features, and leaning on them (Auth, Realtime, Edge Functions, the client SDK) is the thing that makes leaving more work. That coupling is a fair price for the speed; just choose it deliberately.
A reasonable default for many indie and small-team builds: start on Supabase if you have no backend and want to move fast, and reach for Neon when the database is the part you care about and you're bringing your own application tier. Neither choice is a trap — they're optimized for different starting points.
Originally published at pickuma.com. Subscribe to the RSS or follow @pickuma.bsky.social for new reviews.
Top comments (0)