Making Postgres serverless
summary
neon makes Postgres behave serverless by separating storage and compute, using a custom storage layer and proxy, running Postgres in VMs that it can spin up under 1s (claimed ~500–700 ms), suspending idle instances after five minutes, and billing by CPU hours. connection pooling uses PG Bouncer and an HTTP/Edge API for environments that forbid TCP. it reduces cold starts and short-lived connections but still wrestles with Postgres connection state and pooling limitations.
AI-written summary · about
chapters (6)
- 0:00Introduction to Neon
- 1:51What serverless PostgreSQL means
- 3:57Key expectations of serverless systems
- 5:43Neon’s serverless PostgreSQL approach
- 9:53Connection management challenges
- 12:46Future of PostgreSQL and Neon
related talks
26mNeon: How we made PostgreSQL serverless
41mNeon tech - Separation of storage and compute for Postgres
45mPostgres: ServerLESS is more?
33mServerless & Databases - your options and best practices
27mThe world's worst pool party: Connection management with Prisma
36mBest Practices in PostgreSQL Tuning: Navigating Key Performance Bottlenecks in the Cloud
51mScaling Postgres to the next level at OpenAI
20mOpen Source Database Operations in the Age of AI