Neon is a serverless PostgreSQL database platform that separates compute from storage, enabling instant database branching, automatic scaling, and scale-to-zero cost optimization. Built on a cloud-native architecture that disaggregates Postgres into stateless compute nodes and a distributed storage layer, Neon provides GitHub-like workflows for databases—you can create branches in milliseconds, restore any point in time, and autoscale compute resources in response to load. The platform's serverless driver supports WebSocket and HTTP connections for edge and serverless functions, while its branching model enables dev/test/staging isolation without duplicating storage costs—a workflow that transforms how teams build, test, and deploy database-backed applications.
What This Cheat Sheet Covers
This topic spans 22 focused tables and 187 indexed concepts. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.
Table 1: Core Architecture and Serverless Concepts
Almost everything that makes Neon feel different from a traditional Postgres host traces back to one design choice: storage and compute are pulled apart. Once you grasp that the Pageserver and Safekeepers hold your data while stateless compute endpoints come and go, the rest of the vocabulary here—Compute Units, autoscaling, scale-to-zero, branches—falls into place as natural consequences.
| Concept | Example | Description |
|---|---|---|
Storage layer persists WAL; compute nodes are stateless | Neon's architecture disaggregates PostgreSQL into stateless compute and distributed storage, enabling independent scaling and instant branching. | |
0.25 CU = 0.25 vCPU + 1 GB RAM | • Measure of compute resources • 1 CU = 1 vCPU with 4 GB RAM • fractional CUs allow fine-grained sizing | |
Min: 0.25 CU, Max: 4 CU | • Compute automatically scales up or down based on load within configured min/max CU boundaries • reduces cost during idle periods | |
Compute suspends after 5 minutes of inactivity (configurable) | • Idle computes automatically suspend to eliminate charges • wake on first connection in ~500ms (cold start). | |
Typical wake time: 500ms | • Time required to activate a suspended compute • connection pooling and keeping compute active reduce impact |