Neon

In short: A “serverless Postgres” provider — a genuine PostgreSQL database, but without managing your own server, using a connection string instead of a manual installation.

In more detail: In the dashboard you get a connection string (“Connection Details”) that can be viewed in plain text at any time (unlike, say, an API key that is only shown once). Technically it runs completely ordinary SQL, compatible with standard tools such as pg_dump/psql.

Our context: The database behind Emzett — a new, dedicated Neon database was created, and four tables (challenges, custom_roles, rewards, site_settings) were carried over from the old Bellator DB via pg_dump/psql.

In Depth

Separation of storage and compute

Neon technically separates storage and compute: the actual data lives on a distributed storage layer (internally a purpose-built system based on log-structured storage, not Postgres’ classic file-system layout), while the “compute” instance — the actual PostgreSQL process that answers requests — can be started and shut down as needed without any data being lost. This is exactly what makes Neon Auto-Suspend possible, and it’s the core difference to classic “rent a whole server that runs around the clock” hosting (e.g. a classic RDS instance at AWS or a self-managed Postgres server). This architecture is part of a broader trend in database hosting in recent years — “serverless Postgres” — which, besides Neon, also includes providers such as Supabase (which additionally bundles auth, storage and realtime features around Postgres) or AWS Aurora Serverless, though with varying depth of separation between storage and compute.

Branching

A feature that doesn’t exist in this form in a classic Postgres installation: branching. You can create a complete copy (“branch”) of the production database at any time, which initially costs practically no extra storage (copy-on-write — new blocks are only written once data in the branch actually changes). This is useful, for example, to test a risky migration on a copy first before running it against the real production database, or to automatically create a separate, isolated database copy for every pull-request preview deployment (a common CI/CD pattern: one branch per PR, deleted automatically once the PR is merged/closed). Branches can be created via the dashboard as well as via the Neon CLI/API, which integrates well into automated deploy pipelines.

Connection string and pooling

The connection string typically has the form:

postgresql://<user>:<password>@<endpoint>.neon.tech/<database>?sslmode=require

sslmode=require is mandatory with Neon — unencrypted connections are rejected on the server side, which can lead to a cryptic error message if you accidentally test a connection locally without this flag. For connections from serverless environments (e.g. Vercel Functions, which potentially open new connections per request), Neon additionally offers a “pooled connection” string via PgBouncer (a separate connection pooler sitting between the app and the actual Postgres instance) in “transaction pooling” mode. This matters because Postgres itself only allows a limited number of simultaneous connections (typically in the low hundreds for smaller compute sizes) — with many short-lived serverless function calls that each open their own connection, you would otherwise exhaust this limit quickly (“connection exhaustion”). The downside of the pooled connection string: some Postgres features that require a long-lived session (e.g. LISTEN/NOTIFY, prepared statements across session boundaries, or advisory locks) don’t work reliably in transaction-pooling mode — for those you need the direct, unpooled connection.

Compared with the alternatives

Compared with Supabase (which is much broader, including its own auth system and storage buckets), Neon is deliberately kept lean — a pure Postgres database with serverless properties, without additional platform features. Compared with PlanetScale (which is based on MySQL-compatible Vitess, not real Postgres), Neon keeps you fully compatible with the Postgres ecosystem — every tool that talks to “real” Postgres (including pg_dump/psql, see pg_dump and psql) works unchanged.

See also: pg_dump and psql, Drizzle ORM