Neon Postgres is a serverless Postgres platform, presented as a backend from Databricks built on Lakebase Postgres. It separates storage from compute, running stateless Postgres compute nodes on the Neon storage engine, and layers managed auth, a Data API, functions, object storage, and an AI gateway around that core. Any language, framework, or ORM that speaks Postgres connects with an ordinary connection string.[1][2][3]
Quick verdict
Neon Postgres is an Apache-2.0 serverless Postgres platform that separates storage and compute for autoscaling, instant copy-on-write branching, and scale to zero. Paid plans bill metered usage with no minimum beside a permanent free tier; Supabase documents migrating Neon databases with standard pg_dump tooling.[1][2][3][4]
What Neon does
Instant copy-on-write clones of current or past data. A branch is a copy-on-write clone of current or past data; writes land as deltas isolated from the parent, and creating a branch adds no load to production. Branches integrate with the CLI, API, GitHub Actions, and Vercel preview deployments.[1]
Compute scales with demand and suspends when idle. Compute autoscaling reaches 16 compute units on paid plans and 2 on Free; idle compute suspends automatically and accrues no compute charges. Free-plan databases suspend after five minutes and suspension cannot be disabled there.[1][2]
Ordinary Postgres clients and dump tooling work unchanged. Standard Postgres connections apply: psql, drivers, pg_dump, and psql imports work as usual, which is why Supabase documents migrating a Neon database with plain pg_dump and psql commands.[1][2]
Hourly-metered billing with no monthly minimum. Paid plans bill metered compute-unit hours, storage gigabyte-months, and extra branch-months hourly with no monthly minimum; invoices under $0.50 are not collected. A permanent $0 Free plan needs no credit card.[1]
Who it fits and who should skip it
Teams creating a full database per pull request or test run benefit most, since branches arrive pre-loaded with production data and delete cleanly.[1]
Spiky or idle-heavy workloads fit the metering: suspended compute costs nothing, so staging, side projects, and bursty APIs waste less than always-on instances.[1]
Projects wanting managed Postgres plus auth, API, and storage without running separate services fit the bundled backend positioning.[1][2]
Limits to know
Cold starts after suspend are inherent to scale to zero; Free-plan databases always suspend after five minutes with no opt-out, so latency-critical paths need paid-plan configuration.[1]
Self-hosting means an advanced source build of Neon plus patched Postgres with Rust and C toolchains; no turnkey self-hosted package was documented.[1]
Newer services carry plan and region constraints: Functions and Object Storage work on any plan within usage limits, the AI Gateway needs a paid plan with prepaid credits, and all three run in four listed regions.[1]
Moving to and from Neon
Supabase documents a Neon migration with standard tooling. Supabase publishes a Neon-to-Supabase migration: copy the Neon connection string, pg_dump with clean flags, and psql-import into Supabase. Both sides are standard Postgres, so the workflow substitutes directly.[1]
Neon suits teams that treat databases like code branches; Supabase suits teams wanting a broader bundled backend with realtime and edge functions. The migration path keeps either choice reversible.[1][2]
Questions worth asking
How is Neon different from ordinary hosted Postgres?
Does Neon scale to zero?
Yes. Idle compute suspends automatically and accrues no compute charges. Free-plan databases suspend after five minutes and suspension cannot be disabled there; paid plans can disable or configure it.[1]
Can I self-host Neon?
The engine source is Apache-2.0 and its README documents building and running it from source with Rust and patched-Postgres toolchains. That is an advanced source build, not a turnkey self-hosted package.[1]
How do I migrate between Neon and Supabase?
Export with pg_dump against the Neon connection string and import with psql against the Supabase string. Supabase publishes this exact procedure, including schema and table selection flags.[1]
Sources and editorial review
Source research. Reviewed on October 11, 2026. Written by Sanjib Sah. AI assisted; reviewed by a human editor.
We have not run or tested this product.
- Neon homepage
official · Observed October 11, 2026
Homepage copy: Databricks backend positioning, Lakebase Postgres, auth, Data API, Functions, Object Storage, AI Gateway; serverless, branchable, scale-to-zero; Postgres compatibility; GA and plan/region notes for newer services.
- neondatabase/neon on GitHub
official · Observed October 11, 2026
Repository identity: Serverless Postgres description, Apache-2.0 license link and LICENSE file, Rust toolchain, patched Postgres, source build and run instructions.
- Neon pricing plans
official · Observed October 11, 2026
Plans: permanent Free tier terms, pay-as-you-go metering units, autoscaling caps, suspension behavior, SOC 2 and support tiers.
- Neon documentation
official · Observed October 11, 2026
Docs root: backend-for-apps-and-agents positioning, Lakebase Postgres capabilities, framework and ORM connection guides.
- Neon branching documentation
official · Observed October 11, 2026
Branching semantics and workflows: copy-on-write isolation, dev/test/CI use, rewind, CLI/API/Actions/Vercel integration.
- Migrate from Neon to Supabase
official · Observed October 11, 2026
Dated substitutable-workflow procedure: Neon connection string, pg_dump flags, psql import, large-database guidance.
Compared with these products
No explicit proprietary baseline is recorded.