Neon

    Data · Freemium

    Overview

    A cloud version of the Postgres database built to run in a serverless way. It started in 2021. Its design separates compute from storage, which lets it do two things plain Postgres cannot do easily: shut compute off when the database is idle so you stop paying for it, and make near instant copies of a database using copy on write. Those copies, called branches, share the parent's storage and only record changes made after the branch point. In May 2025 Databricks acquired Neon, and has said it will keep the project open source and run it as a separate service.

    What people use it for

    Developers use Neon as the main database behind a web or mobile app. They spin up a full copy of a database for each pull request or test run, then throw it away. They give each developer their own branch with real shaped data instead of a shared staging database. They run side projects and low traffic apps cheaply, since compute sleeps when no one is using it. They back apps built on serverless and edge platforms that open many short lived connections. They also test schema migrations against a branch of production data before applying them for real.

    Key capabilities

    Neon separates compute from storage, which enables scale to zero, autoscaling, and instant branching. Branching uses copy on write, so creating a branch takes about the same time whether the database is 50 MB or 500 GB, and a branch only stores the changes made after it was created. When traffic stops, compute scales to zero and only storage is billed. Autoscaling on the Launch plan extends up to 16 compute units based on load. Neon is Postgres, so existing drivers, tools, and extensions work. It targets serverless and edge apps and offers a connection pooler and an HTTP based driver for those environments. Pricing is a free tier plus paid plans, with usage based charges for compute time and stored data.

    Limitations

    The main catch is cold start. After a quiet period the compute has to wake up, which adds a delay to the first query. Reviews put typical cold starts in the few hundred milliseconds to one second range, with some measuring closer to two seconds at the 95th percentile. For background jobs that does not matter, but for a user facing page it is a visible pause. The storage layer adds a network hop, so input output heavy work like bulk loads, vacuum, and large scans can behave differently than on local disk. Apps with steady traffic get no benefit from scale to zero. Neon is also younger than the big managed Postgres providers, so it has a shorter track record, though the Databricks acquisition adds backing.

    Insight

    Neon's real appeal is branching. Being able to make a full, real shaped copy of a database in seconds, for every pull request or every developer, changes how teams test against production like data, and it does it cheaply because branches share storage. Scale to zero is nice for side projects and idle environments, but it is also the source of the one recurring complaint: the first request after a quiet spell is slow, and for a consumer app that is a poor first impression. Apps with steady traffic never sleep anyway, so they carry the cold start risk with none of the savings. Since it is plain Postgres, moving off it later is not a rewrite. Best for side projects, test environments, and teams that want cheap disposable database copies. Match the compute settings to the traffic pattern rather than leaving scale to zero on everywhere.

    Pricing

    Freemium

    Website

    neon.com

    Last checked 2026-08-30