The Ultimate Guide to Neon: Serverless Postgres

Summary

The video presents Neon as a serverless, managed version of PostgreSQL. It retains PostgreSQL’s familiar SQL, data types, extensions, and connection strings, so existing tools and ORMs—such as Prisma and Drizzle—can connect without using a proprietary API.

How Neon works

Neon’s central design choice is to separate compute from storage:

• Compute: PostgreSQL processes queries using memory and local disk, but does not hold the durable copy of the data. Compute can be replaced or shut down without losing stored data.
• WAL replication: When PostgreSQL writes changes to its write-ahead log, Neon’s replication layer—called “guardians” in the subtitles—copies those changes across multiple nodes.
• Page servers and object storage: Page servers turn the change history into database pages and serve them as needed. Older history is kept in cloud object storage.

The presenter says this architecture allows Neon to shut down idle compute while keeping data durable.

Main features and benefits

• Scale to zero: On the free plan, compute shuts down after five minutes of inactivity and resumes when a query arrives. The presenter describes the wake-up time as a few hundred milliseconds.
• Automatic scaling: Compute can scale between configured minimum and maximum sizes as demand changes, rather than requiring a fixed server size.
• Database branching: Branches are instant, copy-on-write copies rather than full data duplicates. They can be used for developer environments, migration testing, previews, and CI/CD. The demo shows options to branch a schema or data, use a past point in time, and anonymize data.
• Usage-based costs: The presenter argues that separating compute and storage can reduce costs for databases that are idle much of the time. One trade-off is a delay on the first query after compute has been suspended.
• API-based provisioning: Databases and branches can be created and deleted programmatically, making the service suitable for automation.

Use cases and examples

The video highlights workloads with irregular traffic, development and testing environments, and per-tenant databases for B2B products. It also emphasizes AI agents, which may need many temporary databases quickly. The presenter says a Neon Postgres database can be created in about half a second and notes that PostgreSQL’s pgvector tooling can support applications that store embeddings.

As examples of production use, the presenter cites:

• A developer-focused, headless CMS whose name appears as “BassHub” in the subtitles, reportedly using Neon for scaling and isolated migration tests.
• Replit, which offers users instantly provisioned Postgres databases for applications they build.
• Retool, which is said to operate roughly 300,000 databases through Neon’s API, with one engineer managing them.

The presenter also claims that more than 80% of new databases on Neon are now created by AI agents, compared with roughly 30% two years earlier.

Setup walkthrough

The tutorial demonstrates how to:

1. Sign up for Neon and create a project.
2. Copy the project’s connection string for use in an existing Postgres application.
3. Use Neon’s browser-based SQL editor to create a table, insert records, and run a query.
4. Create a development branch, inspect its connection string, and delete the branch afterward.

Main speaker and sources

The video is presented by an unnamed data expert and host, who explains Neon’s architecture, features, use cases, and setup process. The production examples are attributed to BassHub (as captioned), Replit, and Retool.