Neon is a serverless Postgres platform with Git-like branching and scale-to-zero compute. These exercises cover Neon's architecture, branching model, and the features that make it unique for developer workflows.
0 / 5 completed
1 / 5
At standup, a colleague asks what a Neon branch is. What is the correct answer?
Neon branches use copy-on-write storage: a new branch is created instantly because it shares the parent's page files and only diverges when writes occur. Each branch has its own compute endpoint (connection string), allowing completely independent read/write access. This enables Git-like workflows — create a branch for each PR, run migrations and tests against it, then delete it, all without affecting the parent database.
2 / 5
During a PR review, a teammate asks what compute endpoints are in Neon and why a branch without one cannot accept connections. What is accurate?
In Neon's architecture, storage and compute are separate. A branch is a storage concept (copy-on-write page files), while a compute endpoint is the actual Postgres process that reads and writes those pages. A branch without a compute endpoint has no running Postgres — you cannot connect to it. You create a compute endpoint for a branch explicitly (or Neon creates one automatically for the main branch) to enable SQL connections.
3 / 5
In a design review, the team discusses scale-to-zero on Neon. A junior engineer asks what happens when a Neon compute scales to zero. What is correct?
Scale-to-zero suspends the Postgres compute process after a configurable idle period (default 5 minutes). The compute costs drop to zero because no server is running, but storage (and all data) is preserved. The next incoming connection triggers an automatic cold start — typically around 500ms — before queries can be served. This makes Neon cost-effective for development databases and intermittent workloads.
4 / 5
An incident report shows connection pool exhaustion on a Neon database. A senior engineer asks what connection pooling option Neon provides. What is correct?
Neon provides built-in PgBouncer connection pooling. Each compute endpoint has two connection strings: a direct string (standard Postgres port) and a pooled string (typically port 6543) that routes through PgBouncer in transaction mode. The pooled connection supports far more concurrent clients than the Postgres process's max_connections, making it essential for serverless environments where many short-lived connections are common.
5 / 5
During a code review, a senior engineer asks about branch protection in Neon. What does it prevent?
Branch protection in Neon marks a branch (typically main/production) so it cannot be accidentally deleted via the API or console. Protected branches show a lock icon in the Neon dashboard. This safeguard prevents destructive operations on production data. It does not automatically make the branch read-only or enforce schema review workflows — it is purely a deletion guard.