NeonDB

In short: A “serverless Postgres” provider — a genuine PostgreSQL database with no server of your own to manage, with automatic scaling and a connection string instead of manual installation.

In more detail: Neon separates storage and compute: the computing power can shut down completely when idle (“auto-suspend”) and spin back up within seconds when needed, so you only pay for actual usage instead of a permanently running server.

In Depth

The separation of storage (data storage) and compute (computing power for queries) is the central architectural innovation behind “serverless Postgres”: instead of a classic database installation, where storage and computing power are permanently tied to a running server instance, NeonDB keeps the data in a separate, permanent storage layer, while the actual computing power (the “compute” node that actually executes queries) is started as needed and shut down again when idle.

This brings two practical advantages for smaller/medium projects: costs scale with actual usage instead of a permanently booked server capacity, and “branching” becomes easy — a separate, isolated database branch for, say, a test environment can be created in seconds from the current data state, similar to a Git branch, instead of manually creating a complete copy of the database. As a PostgreSQL wrapper, full SQL compatibility is preserved — applications connect via a standard connection string like any other PostgreSQL instance.

Cold starts and auto-suspend in detail

The auto-suspend feature has a practical side effect developers should know about: after a configurable period of inactivity (often a few minutes), the compute node shuts down completely — the next database access then triggers a “cold start”, where the node first has to spin up again before the query is answered. This can show up as a noticeable delay (often in the range of several hundred milliseconds to a few seconds) for the first request after a period of rest — for applications with very strict latency requirements on every single request, this can matter, but for most web applications with irregular traffic, the cost advantage usually matters more than this occasional delay.

Branching as a development tool

The database branching feature changes typical development workflows: instead of manually maintaining a staging or test database and regularly syncing it with production data, a separate, isolated database branch can be created automatically for every feature branch or pull request — with the same data state as at the time of creation, but completely independent of changes to the production database. Changes (e.g. a new migration) can thereby be safely tested against real, realistic data, without touching the actual production database, and the branch can simply be deleted again after merging.

Pricing model and limits

NeonDB’s free and cheaper pricing tiers suit smaller projects and prototypes well, but have limits on storage, compute time, and the number of parallel connections — with strongly growing traffic, a paid plan with dedicated, permanently running compute eventually becomes necessary, at which point the auto-suspend cost advantage matters less. For very traffic-intensive, latency-critical production applications, a classic self-managed or permanently booked PostgreSQL instance can then become more economical again.

See also: SQL, PostgreSQL, Server