I migrated a production application from AWS RDS to Neon in January 2026, and I have been running it alongside a comparable RDS instance ever since to compare costs, latency, and operational friction. The application is a TypeScript API serving approximately 180,000 requests per day with a read-to-write ratio of roughly 12 to 1 — typical for a content-heavy web application with user accounts, session management, and a handful of transactional workflows. After five months of side-by-side operation, I have enough data to separate Neon's genuine innovations from its marketing claims.
What the Storage-Compute Separation Actually Feels Like
Neon's architectural pitch is straightforward: separate the database into a stateless compute layer that processes queries and a distributed storage layer that persists data, then scale them independently. In traditional PostgreSQL, the database server manages both as a single unit, which is why managed Postgres services charge you for provisioned RAM and CPU 24 hours a day even when your database is idle for 22 of those hours.
In practice, the separation manifests as a cold-start penalty. When my application has not queried the database for more than five minutes — the auto-suspend threshold I configured — the compute endpoint suspends, and the next query wakes it up. I measured cold starts consistently across 200 samples: the median cold start took 1.8 seconds, the 95th percentile was 2.6 seconds, and the worst case I recorded was 3.1 seconds. These numbers improved from the 4- to 5-second range I saw in late 2025, and Neon's engineering team has publicly committed to sub-one-second cold starts by the end of 2026, but for now, 1.8 seconds is the reality.
For my application, which serves API requests that users expect to complete in under 300 milliseconds, I could not tolerate cold starts on every request. My solution was to keep the compute endpoint running continuously on the Launch plan, which disables auto-suspend for about $19 per month. This eliminated cold starts entirely — once warm, query latency averaged 2.1 milliseconds for simple SELECT operations on indexed columns, which is indistinguishable from my RDS instance at the same workload level. The difference is that my RDS instance cost $43 per month for a db.t4g.micro with 2 vCPUs and 1 GB of RAM, while Neon's Launch plan with 2 vCPUs cost $19. The architecture saved me $24 per month for equivalent query performance.
Database Branching Is the Feature I Did Not Know I Needed
Neon's branching feature lets you fork a database into an isolated copy in under one second with no data duplication. I was skeptical when I first read about it — database cloning is not a new concept — but the speed and zero-copy mechanism change how you use it.
I integrated database branching into my team's CI pipeline in February 2026. Every GitHub pull request now triggers a GitHub Action that creates a database branch from production, runs the full test suite — including integration tests that require a real database with production-scale data — and deletes the branch when the PR is merged or closed. Before Neon, our CI tests ran against a truncated seed dataset that fit within a Dockerized Postgres container, and schema migration tests were simulated rather than tested against actual production data. The number of migration-related production incidents dropped from three in the six months before the switch to zero in the five months since.
Database branching creates isolated database copies in under one second with copy-on-write semantics — branches share storage with the parent and only the changes introduced in the child consume additional space. I recently branched a 12 GB production database for a schema migration test, and the branch was ready in 0.7 seconds. The branch added approximately 240 MB of storage after running the migration, which is only the delta from the schema changes.
The developer workflow improvement is substantial. A colleague can create a branch from production, run an expensive analytical query that would slow down the primary database, and delete the branch afterward without affecting production performance. Our data team uses this for ad-hoc analytics that previously required a separate read replica or a scheduled maintenance window. The branching API is accessible through both the CLI and the dashboard, and the GitHub integration handles the PR lifecycle automatically.
Where Neon's Performance Differs from Traditional Postgres
I ran a series of benchmarks comparing Neon's Launch plan (2 vCPUs, always-on compute) against an AWS RDS db.t4g.medium instance (2 vCPUs, 4 GB RAM, 100 GB gp3 storage). The workload was a mix of OLTP queries — point selects, range scans, joins across three tables, and batched inserts — simulated through pgbench with a scale factor of 50.
For read-heavy workloads with 90 percent SELECT operations, Neon and RDS were within 8 percent of each other on throughput: Neon handled 1,840 transactions per second at 50 concurrent connections, while RDS handled 1,990. The difference was within measurement noise for most queries. For write-heavy workloads with 50 percent UPDATE and INSERT operations, Neon lagged RDS by approximately 18 percent — 620 transactions per second versus 760 — which Neon's documentation attributes to the additional latency of the WAL write path to the page server. For my application's read-dominant workload, this difference was imperceptible.
Connection pooling is handled by PgBouncer at the endpoint level, which is necessary because the serverless model means each endpoint can scale independently and cannot rely on a persistent connection pool on a known host. I configured my application's connection pool to use Neon's PgBouncer endpoint with transaction mode pooling, which reduced the number of idle connections from 80 to 12 and eliminated the "too many clients" errors I occasionally saw when the application held connections through periods of inactivity.
The Extensions Gap and Other Real Limitations
I want to be direct about what Neon cannot do as of mid-2026, because the limitations have bit me and would bite anyone migrating a non-trivial application.
Neon does not support PostgreSQL extensions that require persistent filesystem access or background worker processes. My application relied on pg_cron for scheduled database maintenance — vacuuming, index rebuilds, materialized view refreshes — and migrating to Neon meant replacing those cron jobs with application-level scheduled tasks triggered by an external scheduler. This was not impossible, but it was an extra migration step that the documentation did not surface prominently. I spent about four hours reimplementing four cron jobs before the application worked correctly on Neon.
The dblink and postgres_fdw extensions are supported, but their connections terminate when the compute endpoint suspends. If you rely on cross-database queries through these extensions and use auto-suspend, you will encounter periodic connection failures. Keeping the endpoint always on resolves this, at the cost of the $19 per month Launch plan.
Storage pricing above the included tiers requires attention. The free tier includes 0.5 GB of storage. The Launch plan includes 4 GB. Beyond that, additional storage costs $0.085 per GB per month, which is competitive with RDS's gp3 pricing but can accumulate quickly if your dataset grows without pruning. My production database is 18 GB and growing at approximately 1.2 GB per month, which means I am paying about $1.19 per month in additional storage on top of the $19 base plan. At my current growth rate, storage alone will cost about $8 per month by the end of 2026 — still significantly less than a comparable RDS instance, but worth tracking.
The Free Tier Is Genuinely Useful, with One Catch
I deployed a side project — a personal analytics dashboard with about 60 MB of data — on Neon's free tier in December 2025. It ran without cost for three months before the data approached the 0.5 GB storage limit. During those three months, the cold-start latency was noticeable — first-page loads after inactivity took 2 to 3 seconds before the data appeared — but once the endpoint was warm, the dashboard felt responsive. For a prototype or a learning project where you are the only user, the free tier is practical and generous compared to AWS RDS's free tier, which expires after 12 months and requires credit card validation.
The catch is that the free tier's auto-suspend behavior cannot be disabled. If your application has even a modest number of regular users who expect sub-second response times, the free tier will frustrate them during periods of inactivity. For anything that faces users, the $19 per month Launch plan is the minimum viable tier.
Originally published at pickuma.com. Subscribe to the RSS or follow @pickuma.bsky.social for new reviews.