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.
