Supabase vs Neon: Pricing, Branching and Auth Compared

Supabase gives you a project. Inside it sit Postgres, auth, file storage, realtime channels and edge functions, all behind one API and one dashboard. You choose a compute size, and it runs all month.

Neon gives you a Postgres project and stops there, apart from a few additions. Compute is metered in CU-hours: one compute unit is roughly 4GB of RAM, and the smallest autoscaling size is 0.25 CU. When nothing has connected for five minutes, compute can go to sleep, and you stop paying for it.

In a Supabase vs Neon decision, the first question is not which is cheaper. It is whether you want a database or a backend. If your app already has its own auth and file handling, Supabase's bundle is partly redundant. If you want to stop writing those parts, Neon leaves them with you.

Neon does, on every plan. On Free the five-minute idle timeout cannot be turned off. On Launch you can disable it, and on Scale you can set it anywhere from one minute to always on. Neon's own docs say waking a compute takes a few hundred milliseconds.

Supabase works the other way. Its pricing page says projects on paid plans are not paused, and compute is a fixed size you pick. The Pro price includes a $10 credit that covers the smallest, Micro. Free projects are the exception: they are paused after one week of inactivity, and someone has to bring them back.

That difference is worth real money on a database that is busy for a few hours a day. It is worth nothing on one that serves requests round the clock, where an always-on Neon compute costs more than a Supabase Micro. Working that out is the next section.

Take a worked example, not a real customer. A small product with one developer, a 2GB database, about 5,000 monthly active users and modest traffic. It needs Postgres and auth, and no more than a few gigabytes of files. Prices are from each vendor's pricing page when checked.

In this Supabase vs Neon example, read the two Neon columns as a range. At 10 busy hours a day the bill is under $9. Leave compute running around the clock and it is about $20, still below Supabase Pro. The gap closes if you need more. Step up to 0.5 CU, which is 2GB of RAM, and run it always on: 365 CU-hours x $0.106 = $38.69, plus $0.70 storage, is $39.39. Supabase Pro with a Small compute is about $30: $25, plus $5 for the $15 Small above the $10 credit.

Two caveats keep this honest. First, Supabase Pro bundles more: 100GB of file storage, 250GB of egress and realtime messages, where the Neon pricing page lists 500GB of egress and no file storage. Second, neither bill covers where your app runs. Add that separately, or use a platform that includes it. Helm7 starts at $12 a month for the app, Postgres, auth and storage together, with usage drawing down against that minimum.

Recovery is the other place bills diverge. On Supabase, point-in-time recovery is an add-on at $100 a month per 7 days of retention, and it needs at least a Small compute. Neon lists a restore window of up to 7 days on Launch, with the history counted as storage. Our guide to Postgres point in time recovery explains what you are paying for either way.

Both offer branches, and in the Supabase vs Neon contest they solve different problems.

On Neon, a branch starts with your data. It is instant, it adds no load to the parent, and you can create one from an earlier point in time. That makes a branch per pull request, or a branch to test a risky migration against real rows, cheap and normal. Our Neon review covers the billing side.

A Supabase branch is a whole separate environment, with its own instance and its own API credentials. It starts empty by default. Supabase says new branches do not start with any data or storage objects from your main project, and offers seed files or an Include data option instead. The pricing page lists branches at $0.01344 an hour, which is about $9.81 over a 730-hour month if one stays open.

• Choose Neon branching to test migrations against real data or to give every pull request a database.
• Choose Supabase branching to preview the whole backend: auth settings, edge functions and API keys, not just the schema.

Supabase auth is part of the product from the first minute, and it stores users in your Postgres database. Its client library, supabase-js, is what a lot of tutorials and starter kits assume. That is a real advantage: less to choose and less to wire.

Neon now has an auth product too. Its docs say it is built on Better Auth, that your Neon database is the source of truth for authentication data, and that auth branches along with your database. The pricing page lists up to 60,000 monthly active users on Free and up to 1M on Launch and Scale. It is newer, and it has far less written about it.

On lock-in: Supabase's pieces are open source, and you can run the whole stack yourself, as our piece on self hosted Supabase shows. Neon is standard Postgres, so leaving it is a dump and restore. Neither is a trap. The cost of moving is in your code that calls the auth client, not in the database.

We compete with both, so weigh this accordingly. Helm7 is the better fit when the database is one part of an app you also want hosted, and you would rather have one invoice. It is the wrong fit for realtime features, and the wrong fit for a US audience.

On Supabase vs Neon for a new small project with no strong opinions, we would start on Neon's Free or Launch plan if the app has its own auth, and on Supabase Pro if it does not. The Neon cost stays low while the app is quiet. The Supabase cost buys you three things you would otherwise build.

For a team that already has steady traffic and lives in the Supabase client, stay put. Moving saves little and costs a fortnight. The place to be sceptical of both is the bill after year one. Re-run the arithmetic above with your real CU-hours, and re-check the pricing pages, because both change.