Neon vs Supabase vs AWS RDS for Postgres (2026)

Postgres is the easy decision. Where to run it is the one founders keep reopening: Neon, Supabase and AWS RDS all host the same open-source database, yet they bill, sleep, branch and lock you in very differently. Pick wrong and it shows up as a $100 add-on nobody budgeted for, or a week of AWS networking before the first feature ships.

Where should a SaaS host its Postgres database?

For most SaaS MVPs, host Postgres on Supabase if you'll use its built-in auth, storage or realtime, and on Neon if you only need a database; choose AWS RDS or Aurora when you already run on AWS or a customer's compliance team requires it. All three run standard Postgres with a London region, so the choice is reversible.

They sell different things. Neon sells a serverless database: compute that scales to zero when idle, and branches of your data in seconds. Supabase sells a backend: Postgres plus auth, file storage, realtime and an auto-generated API for a flat monthly fee. RDS sells a managed database server inside your own AWS account: the most control, the most configuration and nothing extra in the box.

How do Neon, Supabase and AWS RDS compare?

Prices are in USD as of October 2026, from Neon's pricing page, Supabase's pricing page and AWS's RDS pricing for London (eu-west-2). Vendors change pricing, so check before you commit.

Two rows decide most MVP choices. Scale-to-zero is why Neon can cost almost nothing for a product that's quiet overnight, at the price of a slightly slower first query after a lull. Branching is why it suits teams that want a real database behind every preview deployment. Supabase answers both rows with "no, but here's auth, storage and realtime" — often the better trade.

What will each one cost at MVP stage?

Illustrative estimates from the prices above, comparing like with like: 1 GB of RAM in (b) — Neon 0.25 CU, Supabase Micro, RDS db.t4g.micro — and 2 GB in (c) — Neon fixed at 0.5 CU, Supabase Small, RDS db.t4g.small. AWS lines use a 730-hour month; data transfer and tax are excluded.

• (a) Validating: a founder and testers; under 500 MB of data.
• (b) Launched: first paying customers; 2 GB of data; traffic mostly in UK working hours (~400 active hours a month); production plus staging.
• (c) Growing: ~10 GB of data; traffic around the clock; 7-day point-in-time recovery; production plus staging.

For Neon we assume 1 GB of restore history in (b) and 5 GB in (c), and a staging branch using 20 CU-hours and 0.5 GB in (b), 30 CU-hours and 1 GB in (c).

Three things stand out:

• Neon is cheapest when your product is idle, and only then. An uptime check or polling worker that queries every few minutes keeps it awake, and always-on at the smallest size is 0.25 CU × 730 hours × $0.106 = ~$19.
• Supabase's step change is point-in-time recovery, not users. Neon bills restore history as cheap storage and RDS covers it within its free backup allowance; Supabase's PITR is a $100 add-on. But its $25 also buys auth, storage and realtime, so compare whole bills — see Supabase pricing explained.
• RDS has the cheapest always-on compute and the most expensive hours. Someone has to own the VPC, security groups and upgrades. And serverless apps want a pooler: RDS Proxy bills $0.017 per vCPU-hour in London, so on a 2-vCPU db.t4g instance it's 2 × $0.017 × 730 = $24.82 a month — more than the micro database behind it.

When should you pick Neon, Supabase or RDS?

Neon when the app only needs a database: server-side queries through an ORM such as Drizzle or Prisma, bursty or office-hours traffic, and a branch per pull request. Since joining Databricks, Neon has added auth, object storage, functions and a beta realtime service, but in London only Postgres and auth are available, and all of it is far newer than Supabase's.

Supabase when you'll use the extras: file uploads, live updates, Supabase Auth, or its auto-generated API secured with Row-Level Security. You get an always-on server, daily backups and those services for a forecastable $25.

RDS or Aurora when AWS is a given: your other services already run there, an enterprise buyer wants the database in your own account behind a private network, or you need AWS's business associate agreement for health data. Aurora Serverless v2 ($0.14 per ACU-hour in London) can pause at zero capacity, but resuming takes ~15 seconds, and attaching RDS Proxy stops it pausing at all. It suits staging better than production.

Which Postgres works best with Vercel, Next.js and Clerk?

On Vercel, Neon is the path of least resistance; with Clerk, any Postgres works. Vercel Postgres no longer exists — Vercel moved its databases to Neon in December 2024 — and the Vercel Marketplace offers Neon, Supabase and, since December 2025, Aurora PostgreSQL. Neon's integration creates a database branch for each preview deployment.

Serverless functions open many short-lived connections, so connect through a pooler: Neon's -pooler hostname or its @neondatabase/serverless driver over HTTP, or Supabase's transaction-mode pooler on port 6543. RDS sits in a private network by default, so reaching it from Vercel means exposing it behind strict security groups or extra networking work — the trade-offs in Vercel vs AWS for a SaaS MVP apply to the database too.

Clerk stores users and organisations itself; your tables hold Clerk's IDs, kept in sync by webhooks. The host only matters if you want Row-Level Security to read Clerk's token directly: Supabase supports Clerk as a third-party auth provider, and Neon's Data API verifies Clerk tokens via their JWKS URL.

Can you move between Neon, Supabase and RDS later?

Yes — all three run standard Postgres, so moving is an operations task, not a rewrite. Two routes:

• Dump and restore. pg_dump from the old host, pg_restore into the new one, during a short maintenance window. Simplest for an MVP-sized database.
• Logical replication. Subscribe the new database to the old one, let it catch up while the app runs, then switch the connection string. Downtime is close to zero. On RDS you enable it through a parameter group; on Neon, a connected subscriber keeps the source compute awake.

Check that the target supports your extensions and the same or a newer Postgres major version. What doesn't move is anything beyond plain Postgres: leaving Supabase means migrating users off Supabase Auth and files out of its storage; leaving AWS means rebuilding IAM and networking, not data.

Can your Postgres stay in the UK?

Yes, on all three — choose London when you create the database. Neon's London region (aws-eu-west-2) runs Postgres and auth, but not yet its other services, and a Neon project's region can't be changed later. Supabase lists London (eu-west-2) as a specific region; pick it rather than the general "Europe" option, which can place a project in several countries, including non-EU ones. RDS runs in London as eu-west-2.

UK data protection law doesn't by itself require UK hosting, but a London region keeps transfer paperwork simple and answers the first question UK buyers ask. You still need a data processing agreement with the provider, named in your sub-processor list. This is general guidance, not legal advice.

Our default: Postgres on Supabase or Neon, RDS when AWS is a given

Our default stack is Next.js, Postgres (often on Supabase), Clerk, Stripe and Resend on Vercel — reasoning in our SaaS MVP tech stack for 2026.

Supabase Pro when the product uses more than the database — storage, realtime, Supabase Auth or RLS through its API. One vendor, one flat bill. Neon when the app only reaches its database from server-side code, typical of a Next.js app on Clerk, especially with office-hours traffic. RDS when the client already runs on AWS or a regulated buyer requires the database in the client's own account — a requirement, never a preference.

Whichever host: a London region, a paid plan before customers arrive, a pooled connection from day one, and a restore you've actually rehearsed. Setting that up is part of our DevOps and cloud infrastructure work. All three run pgvector; when that's enough for AI retrieval is covered in pgvector vs Pinecone.

Frequently asked questions

What is the best database to pair with Clerk?

Postgres, on whichever host fits the rest of your stack — Supabase, Neon and RDS all work. Clerk doesn't need a particular database: it keeps users and organisations itself, and your tables reference Clerk's IDs. Supabase and Neon can also verify Clerk's tokens for Row-Level Security; on RDS, your server code sets the user and tenant per request, as most Next.js apps do anyway.

Should I choose MongoDB Atlas or Neon for a new application?

Neon, or another Postgres host, unless your data is genuinely document-shaped. Most SaaS data is relational — users, organisations, subscriptions, invoices — and Postgres's jsonb covers the occasional flexible field. Atlas is the right call for self-contained documents you rarely join, a team that knows MongoDB deeply, or early horizontal sharding. Both sides are in Postgres vs MongoDB for a SaaS.

What about Google Cloud SQL, Railway and other Postgres hosts?

They're sound when they match where the rest of your stack lives. Google Cloud SQL is Google's counterpart to RDS, with the same operational trade-offs; pick it if you're already on Google Cloud. Weighing Atlas against Cloud SQL is the Postgres-or-MongoDB question again. Railway and Render suit teams running several services in one place.

Want your database chosen and costed before you build?

Where your Postgres lives gets decided in week one, along with its region, pooling, backups and staging. To make those choices deliberately, book a free scoping call. We'll map the right stack to your product, running costs included, and quote the build fixed-price.