Neon or Supabase: which Postgres for your data?
Neon and Supabase both run PostgreSQL, but they sell something different. A comparison in three tables, and when to pick which.
In the article on SQL I wrote that I work with PostgreSQL. The question that always follows: where does that database actually run? For a smaller company, two names come out on top today: Neon and Supabase. Both PostgreSQL, both with a free tier, both popular. Yet they sell something different.
The difference in one sentence
Neon sells a database. Supabase sells a complete backend that happens to have a database inside.
That sounds like a detail, but it decides everything: how you pay, what you get with it and who it is meant for.
What they are
| Neon | Supabase | |
|---|---|---|
| Core | Serverless PostgreSQL | PostgreSQL with a backend around it |
| Owner | Databricks (since 2025) | Independent |
| What you get with it | Branching, automatic scaling up and down | Login, file storage, realtime, functions, automatic API |
| Compute | Scales to zero when nobody asks | Always on |
| Meant for | Data, pipelines, apps with their own backend | Apps that need a complete backend fast |
| European regions | Frankfurt, London | Including Frankfurt, Paris, Stockholm, Zurich, London |
Neon now has its own login and API as well, but the core is still the database. At Supabase, the database is one of the building blocks.
What it costs
This is where the biggest difference sits, and it is a difference in model, not in price.
Neon charges per use. You pay for the hours the database computes and for storage. If it sits idle, you pay nothing. Supabase charges a fixed amount per month, with a fixed server that is always ready.
| Neon | Supabase | |
|---|---|---|
| Free plan | 100 compute hours and 0.5 GB per project | 2 projects, 500 MB database |
| Free plan: the catch | Scales to zero after 5 minutes (cold start) | Project pauses after a week without use |
| Entry paid plan | Launch: pay as you go, no minimum | Pro: $25 per month, smallest server included |
| Compute | $0.106 per compute hour (Launch) | Fixed server size, from $10 to thousands per month |
| Storage | $0.35 per GB per month | 8 GB included in Pro, then $0.125 per GB |
| Restore to a point in time | 7 days in Launch, 30 in Scale | Daily backups; point-in-time restore is an add-on from $100 per month |
| Test copy of your database | Branches included | Branches charged per hour |
Prices in dollars, as both providers bill. As of September 2026.
What that means for reporting
A reporting database does nothing for most of the day. An ETL pipeline pulls in the data at night, Power BI refreshes a few times a day, and in between it is quiet.
That pattern fits Neon perfectly. If your pipeline runs fifteen minutes a night and your report refreshes four times a day, you often stay within the free plan, and otherwise you pay a few euros. With Supabase you pay that $25 a month, including all the hours nobody asks anything.
Supabase wins the opposite story: an app where people log in all day, upload files and see data change. Then the database is always on anyway, and you get login, storage and realtime without building them yourself.
The traps
Neon: the cold start. After five minutes of silence the database goes to sleep, and the first question after that takes a little longer. For a nightly pipeline or a report refresh that makes no difference. For an app where a customer presses a button it does, and then you turn it off in a paid plan.
Supabase: the free plan pauses. A project that goes unused for a week is paused. Fine for a test, a risk for a report you look at every Monday. If you move to Pro, you have a fixed cost.
Both: you choose the region when you create the project. Neon does not let you change it afterwards. Pick Frankfurt or another European region straight away, so your data stays inside the EU. See also the article on GDPR.
Which one do you pick?
| Situation | Pick |
|---|---|
| Reporting database for Power BI | Neon |
| ETL pipeline that runs at night | Neon |
| Quickly wanting a test copy of your data | Neon |
| An app with login and file storage | Supabase |
| Data that has to update live on a screen | Supabase |
| A small team without its own backend developer | Supabase |
And if you are in doubt: because both are PostgreSQL, you are not locked in anywhere. Moving a database from one to the other is a standard export and import. The SQL stays the same.
Why I use Neon
My work is reporting. The database gets its data from pipelines that run at fixed times, and Power BI reads it out. I do not need login or file storage, because Power BI handles that itself.
Then I would rather pay for what actually happens than for a server that waits. I use branches to test a change to the data model on a copy first, without the live report noticing anything.
If I were building a customer portal tomorrow, I would look at Supabase.
The claim
Neon or Supabase is not a choice between good and bad. It is a choice between paying for use and paying for readiness. Know what your database does all day, and the choice makes itself.