Neon or Aurora?

The short version

Why Neon is my default

Most of what I build is a new app on Lambda or Workers, with load that comes and goes. Neon fits that shape. It scales to zero when nobody is using it, so a quiet app costs storage and nothing else. Branches are my favourite feature: a full copy of the database per preview environment, in seconds, thrown away with the pull request.

The connection story is the other half. With Neon's HTTP driver, a Lambda talks to Postgres with no VPC, no NAT and no RDS Proxy. On Aurora that same Lambda goes through RDS Proxy, which is extra config and the part of Aurora I like least. One Postgres with JSONB and pgvector also replaces a separate NoSQL store and a vector database at my clients' scale.

Two things to size properly. The pooled endpoint accepts 10,000 clients, but real concurrent transactions are about 90% of max_connections: roughly 94 at 0.25 CU, 377 at 1 CU. Size compute for transactions, not clients. And the HTTP driver has no interactive transactions: use the serverless driver's WebSocket mode when you need a session.

Watch item: Databricks bought Neon in 2025. Prices went down since, and it still runs as its own product.

When it has to be Aurora

• The client must stay all-AWS. IAM, VPC-only networking and AWS compliance. Aurora is my choice here, and size doesn't change it.
• Bedrock Knowledge Bases on SQL. Aurora is the only Postgres they support, so the chunks are queryable with SQL next to the app's data. If you only need the knowledge base, S3 Vectors is the cheapest store behind it.
• Heavy, constant or global load. High throughput, high availability, geo-replication. Aurora gives me peace of mind and scales well, and at that scale it can be cheaper than Neon.
• Live tables joined with the lake. Since 30 September 2026, aurora_analytics (DuckDB inside) reads Parquet and Iceberg in S3 as foreign tables, at no extra charge. Read-only, PostgreSQL 17.11+ or 18.6+. Athena or DuckDB? covers the lake.

Serverless v2 or provisioned. Serverless v2 is cheaper for low or bursty traffic and scales on its own; provisioned is cheaper for large steady load. One cluster can mix them: a provisioned writer and Serverless v2 readers. Don't pause a production database that serves users: the resume takes about 15 seconds.

Bring the price down with commitments. Aurora is the most expensive way to run Postgres I know, and Savings Plans and Reserved Instances are how I make it reasonable. In Sydney, a db.r7g.large goes from $0.333 an hour on demand to $0.256 (1-year Reserved Instance, no upfront) or about $0.176 (3-year, all upfront). Aurora Serverless isn't an instance: cover it with a Database Savings Plan (1-year, up to 35%).

When both

Across clients, all the time. Neon for new products, prototypes and most client apps; Aurora for the client who must stay inside AWS. Data residency doesn't split them: Neon is available in Sydney, and Aurora runs in the client's own Sydney account. Better Auth keeps users in Australia on either, since they sit wherever the database is.

Not as dev and prod of one app. It's tempting to run previews on Neon branches and production on Aurora. I wouldn't. A compliance client's data shouldn't leave AWS for a preview, and Bedrock Knowledge Bases and aurora_analytics exist only on Aurora, so the previews would test a different database.

Over the life of an app. Both are Postgres, so starting on Neon doesn't trap you. If an app grows into Aurora territory (a client that now requires all-AWS, or steady heavy load), the move is Postgres to Postgres:

• It can take an hour offline and it's small: a native dump and restore. Simpler, fewer moving parts.
• It can't: AWS DMS, full load then change data capture until you switch the app, so the cut-over takes minutes. Create the target schema first: DMS creates tables and primary keys only.

The reverse also happens: when the database is the biggest line on the AWS bill and the app doesn't need Aurora, Neon is often cheaper than any commitment on it.

Traps

• DMS truncates large JSON. It treats Postgres JSON as a LOB, and limited LOB mode stops at 32 KB by default. A Neon app that leans on JSONB documents must measure its largest values and raise Max LOB size first.
• Tables without a primary key drift. DMS ignores their updates and deletes during change capture. Add keys before migrating.
• A Postgres source keeps WAL until DMS reads it. An idle task fills the source disk. Turn on HeartbeatEnable, alarm on slot lag, drop the slot when done.
• RDS Proxy pins sessions on SET, prepared statements, temporary tables, advisory locks or statements over 16 KB, and pinned sessions exhaust the pool. Watch DatabaseConnectionsCurrentlySessionPinned.
• Neon's storage bites on write-heavy history. At three times Aurora's price per GB, a database that keeps every raw reading forever is where Neon stops being the cheap option. Keep a retention window and move the rest to the lake, as the IoT guide does.
• Neon's Terraform provider is in transition. kislerdm/neon was archived on 11 September 2026 at 0.18.0, and Neon will publish it as neondatabase/neon. Pin the version, and switch with terraform state replace-provider when it lands.

Sources, checked on 24 October 2026: Neon pricing, Aurora pricing, Aurora PostgreSQL direct querying of Iceberg and Parquet, Database Savings Plans pricing, AWS DMS pricing, PostgreSQL as a DMS source.