Neon vs Supabase vs RDS: Picking a Postgres Host for a Dockerised Stack

You’ve got a Dockerised Django/FastAPI/Next.js app, you need a Postgres host, and every comparison article you open seems to be grading Neon, Supabase, and RDS on the same scorecard as if they’re interchangeable. They’re not. Here’s the direct answer: Neon is serverless Postgres infrastructure, Supabase is a backend platform that happens to be built on Postgres, and RDS (specifically Aurora Serverless v2, if you want elastic capacity) is provisioned Postgres living inside your AWS account. If you’re asking “which one is faster” or “which one is cheaper” without first asking “what am I actually buying beyond a database connection string,” you’ll pick wrong.

Because your app is containerised, the database host doesn’t need to match your deployment platform — containers are designed to ship to any cloud, which is exactly what decouples this decision from the “where do I run my app” decision. That decoupling is the whole reason this comparison is worth doing carefully instead of defaulting to “whatever my hosting provider bundles.”

These Are Three Different Product Categories, Not Three Rows in One Table

One useful framing treats Neon as serverless Postgres infrastructure optimised for developer workflow — branching, preview environments, cheap throwaway dev databases — while Supabase is optimised for time-to-working-app, bundling the database with the scaffolding most apps need around it. Under that framing, the two aren’t strictly competing on the same axis, even though search results lump them together because both have free entry tiers.

RDS — and specifically Aurora Serverless v2 if you want capacity that flexes with load — is a third category again: provisioned Postgres (or an Aurora-flavoured variant of it) that lives inside your existing AWS account, subject to your VPC, IAM policies, and backup tooling. If your organisation already has AWS infrastructure, compliance tooling, or a platform team that owns networking, Aurora isn’t competing with Neon and Supabase on features — it’s competing on “does this database live where the rest of our infrastructure already lives”.

So the real question isn’t “neon vs supabase” in the abstract. It’s: do you need bundled backend features, do you need branching for preview environments, do you need AWS-native integration, and what does your idle/traffic shape actually look like? Answer those four and the host picks itself.

Idle Behaviour and Cold Starts: Scale-to-Zero Isn’t One Thing

This is where the three diverge hardest, and where vendor marketing gets slipperiest. Neon’s architecture separates storage from compute, which is what allows compute to suspend entirely when idle. On Neon’s free tier specifically, compute suspends after 5 minutes of inactivity, and that idle timeout can’t be disabled on that plan. The next query after suspension triggers a cold start while compute spins back up.

How long that cold start actually takes is genuinely unsettled across sources, with published figures varying considerably depending on who measured it and under what conditions. Don’t take any published number as a guarantee for your workload — test it yourself against your actual query patterns and connection setup before you build a user-facing feature that assumes a warm database.

Supabase handles idleness differently and at a different cadence: free-tier Supabase projects are paused after a period of inactivity — commonly reported as about a week, rather than minutes — and paused free-tier projects are generally reported to need a manual “Resume” action from the dashboard rather than waking automatically on the next connection; confirm current behaviour in Supabase’s docs before relying on it. That’s a materially different failure mode from Neon’s — a forgotten side project on Supabase’s free tier is unlikely to silently wake on the next request; it will likely sit paused until a human intervenes, which has reportedly spawned its own cottage industry of keep-alive cron jobs and GitHub Actions workflows to ping free projects before they pause.

Aurora Serverless v2 sits in a third position: AWS has announced that it can now scale to zero Aurora Capacity Units where auto-pause is configured, in addition to the usual auto-scaling between a minimum and maximum capacity you set. Whether this applies to your setup depends on your engine version and configuration, so check AWS’s own documentation rather than assume it behaves the same way as Neon or Supabase. If you rely on this for a genuinely quiet workload, test and measure the resume latency yourself before depending on it for anything user-facing.

The practical takeaway: if idle cost matters to you — a staging environment, a low-traffic side project, dozens of preview branches — Neon’s per-second suspend behaviour is the most aggressive about not charging you for silence, Supabase’s week-long pause is coarser and requires manual or scripted intervention, and Aurora can also scale to zero where auto-pause is configured, though whether it does so — and how quickly it resumes — depends on your engine version and configuration, so check AWS’s documentation and test resume latency for your own setup.

Architecture: Why Neon Can Branch a Database and Supabase Can’t

Neon’s storage/compute separation isn’t just what enables scale-to-zero — it’s also what makes copy-on-write database branching cheap, because a branch shares unchanged storage pages with its parent instead of copying the whole database. That’s the feature that makes Neon genuinely compelling for a Dockerised app with a CI pipeline: spin up a fresh branch per pull request, run migrations and tests against it, tear it down, repeat.

Supabase has no native equivalent. Development workflows on Supabase typically fall back to separate projects per environment or manual dump-and-restore processes. If your team leans heavily on ephemeral preview environments per PR, that absence is a real cost, not a cosmetic one — budget for building that workflow yourself if you go with Supabase.

There’s a trade-off buried in Neon’s architecture worth naming honestly: Postgres is running on a storage layer it wasn’t originally written against, which introduces failure modes that differ from Postgres on conventional disk, even though the architecture has been in production use for some time. That’s not a reason to avoid Neon — it’s a reason to test failure recovery yourself rather than assume vanilla-Postgres operational behaviour carries over unchanged.

Supabase Is a Platform, Neon Is a Database

This is the dimension most “neon vs supabase” searches are actually circling. Supabase bundles the database with a broader platform offering — auth, storage, realtime, auto-generated APIs, and edge functions — rather than shipping just a database; see Supabase’s docs for current details. If your Dockerised app needs auth and file storage and you’d otherwise be wiring up three separate services, Supabase collapses that into one bill and one dashboard.

Neon, by contrast, is centred on the database and the developer workflow rather than a bundled application platform. It has added optional features over time, such as auth and a Data API, so check Neon’s docs for its current feature set. Even so, it remains far narrower than Supabase’s bundled platform, which includes storage, realtime, and edge functions — so teams typically still bring their own ORM (Drizzle, Prisma, SQLAlchemy, whatever your Django/FastAPI stack already uses), their own API layer, and, if already in use, Django’s own auth system. For a team that already has Django’s auth system or a dedicated auth provider wired up, that’s not a gap — it’s the correct amount of surface area, because you’re not paying for or fighting against platform features you don’t need.

For a serverless or edge runtime specifically, Neon also offers a first-party driver that talks over HTTP or WebSockets instead of a raw TCP socket, which lets something like a Cloudflare Worker query Postgres without holding a persistent connection open. That’s a meaningful detail if part of your stack runs at the edge; it’s irrelevant if your containerised backend holds long-lived connections from inside a VPC, which is the more common case for a Dockerised Django/FastAPI service and tends to favour a conventional pooled connection instead.

Aurora offers a direct socket connection from inside the VPC; an HTTP-style Data API may also be available for some configurations, but this is worth verifying against AWS’s own documentation for your specific engine and version before relying on it. Aurora is the strongest option specifically when the database needs to live inside an AWS account that already has the VPC, IAM, and backup tooling set up — you’re not fighting your platform team’s existing conventions.

Pricing Shape, Not Just Headline Price

Free-tier comparisons miss the point if you stop at the headline number. Neon’s free plan includes a limited number of branches per project along with compute metered in CU-hours — check Neon’s plans page for current limits, as these are subject to change. Aurora Serverless v2 is billed on capacity units (ACUs); see AWS’s pricing page for rates for your region and engine. For Supabase, check Supabase’s pricing page for how compute is billed on paid plans.

A genuinely useful cost comparison goes well beyond the sticker price: compute and storage, data transfer, backup retention, branch or project usage, platform add-ons, observability tooling, the engineering time to build what a platform gives you for free, and migration risk if you need to leave. None of the three vendors make that comparison easy, because none of those dimensions show up on the pricing page’s headline row.

Dimension	Neon	Supabase	Aurora Serverless v2
Category	Serverless Postgres infrastructure	Backend-as-a-service platform on Postgres	Provisioned Postgres inside your AWS account
Idle behaviour	Free plan suspends compute after a period of inactivity (per Neon’s plans docs; verify current limits)	Free tier projects are paused after a period of inactivity (commonly reported as about a week), with manual resume	Can scale to zero where auto-pause is configured; depends on engine version and configuration — check AWS docs
Branching	Native copy-on-write branching	No native branching; separate projects or dump/restore	Not a feature of this product
Bundled platform features	Database-first; some optional auth/API features (check Neon docs); no bundled storage/realtime platform	Auth, storage, realtime, auto-generated APIs, edge functions	None — database only
Natural fit	Dev workflow, preview environments, edge-adjacent apps	Apps that want auth/storage/API bundled in	Teams already inside AWS with existing VPC/IAM/backup setup

Every cell above is qualitative or directly tied to the claims above — for actual numbers, check each vendor’s current pricing page before you commit, because rates change and vary by region and engine.

What to Actually Test Before You Commit

Don’t take any of this on faith — including this article. The responsible move is to directly test branching, connection pooling, migrations, restore behaviour, regional placement, and failure recovery against your own workload before you wire a production app to any of these three. Specifically:

• Cold starts: run your actual query patterns against a suspended Neon branch or a paused Supabase project and measure wake time yourself — published figures disagree by an order of magnitude depending on source.
• Pooling under load: a Dockerised backend typically holds a pool of long-lived connections; confirm how each host’s pooler behaves under your container’s connection count, not a toy benchmark.
• Migrations and restore: run a real migration and a real point-in-time restore in a throwaway environment before you trust it in production.
• Exit cost: because all three are still Postgres under the hood, a standard pg_dump/pg_restore should move your data between them — but platform-specific features (Supabase’s auth tables, Neon’s branch structure) don’t travel with a plain dump, so factor that lock-in into your decision now rather than at migration time.
• Self-hosting as a baseline: Postgres itself is open-source and can be run in your own Docker Compose stack for local development or as an escape hatch, which is worth keeping in mind as the ultimate exit option if a managed host’s pricing or behaviour changes underneath you.

The Verdict, Mapped to Workload

If you want cheap, branchable databases for a CI pipeline with lots of preview environments and you’re happy to own your own auth and API layer, Neon fits. If you want auth, storage, and an auto-generated API bundled in so you can ship faster and you don’t need per-PR database branches, Supabase fits. If your database needs to live inside an existing AWS account’s VPC and IAM boundary, or your traffic never truly goes idle, Aurora Serverless v2 fits — and even for idle workloads, Aurora can scale to zero where auto-pause is configured, though you should verify this against AWS’s documentation and test resume latency for your engine version before relying on it. None of the three is the wrong choice in general — only wrong for a workload whose shape doesn’t match what it was built for.

FAQ

Is Neon or Supabase faster? Neither source material nor vendor claims settle this cleanly — published cold-start figures vary by source and measurement method, and Supabase’s always-on paid tier avoids cold starts entirely by design. Measure against your own query patterns rather than trusting a single benchmark.

Can I use Neon and still get auth and storage? Yes. Neon offers some auth and API features, but it is not a full backend platform like Supabase, so check Neon’s docs for its current feature set and pair it with your own storage and auth as needed — for example, Django’s built-in auth — rather than expecting a bundled solution.

Does my Dockerised app lock me into one host? No — containers are built to run anywhere, which is precisely what lets you swap the Postgres host independently of where the app itself deploys.

Is Aurora Serverless v2 the same as “scale to zero”? AWS has announced that Aurora Serverless v2 can scale to zero Aurora Capacity Units where auto-pause is configured, rather than only resizing between a non-zero minimum and maximum. Whether this applies to your setup depends on your engine version and configuration, and resume latency should be tested for your own workload — check AWS’s documentation for the specifics.

What if I just want plain Postgres with no platform features? That’s closest to Neon’s model (database-only) or to self-hosting Postgres yourself in a container, which remains the ultimate vendor-neutral fallback.