Neon vs PostgreSQL
Two sides of the database decision: managed database and run it yourself. When each fits, what it costs, who moves from one to the other, and what makers who chose it say.
Which fits you
- Your traffic is bursty or you run many preview deploys, and idle hours shouldn't cost much
Use it whenYou want every pull request's preview deploy to get its own copy of the database.
Trade-offCold starts after idle periods add latency to the first query, and heavy always-on workloads can cost more than a fixed server.
- You already run your own server and want a flat monthly cost
Use it whenYou already run a server, or want extensions and settings a managed provider doesn't offer.
Trade-offBackups, upgrades, failover and connection pooling are yours to set up and watch.
At a glance
| Used by | 95 makers' products · 16 open-source projects | 74 makers' products · 542 open-source projects |
|---|---|---|
| Cost at default usagedatabase size 8 GB, data transfer 50 GB, document or row reads 10 million reads, document or row writes 2 million writes | $22/mo Launch | — |
| Moved to it on GitHubpull requests since Oct 2024 | 41 from PostgreSQL | 29 from Neon |
| Downloads | 3.7M/wk+35% vs npm | 45.1M/wk+18% vs npm |
| Pricing | Free tier; usage-based paid plans. · paid from $0.106 per CU-hour | Free and open source under the PostgreSQL License; you pay only for the server or managed service that runs it. |
| Free tier | Yes | Yes |
| Open source | Yes · self-hostable | Yes · self-hostable |
Who moves from one to the other
Public pull requests on GitHub since Oct 2024 whose title says "Neon to PostgreSQL" or the reverse — real code changes, by developers in general rather than makers only.
- Switch Phase 0 Postgres from Compose to Neonthomasnoe/fulfillment-exception-triage · 2026-09-19
- fix(render): move dev Postgres to external NeonMemoFlow/memoflow-api · 2026-09-14
- infra: move local Postgres to Neon, add staged startup for resource-c…pranav2004-bit/DECENTRALISED-SLOT-BOOKING-SYSTEM-USING-BECKN-PROTOCOLS · 2026-09-01
- feat(infra): cut Postgres over to Neon (CAL-152, Teams-only)caseyluna/hoop-brain · 2026-08-30
- Move production Postgres from Render free tier to Neonadab-tech/globalopportunities · 2026-08-25
- Port Postgres from Fly to Neonjeffko77/learn2drive · 2026-08-21
- Move DB hosting from Render Postgres to Neonconorlum/ValoMaths · 2026-08-17
- CI builds its own Postgres instead of talking to NeonDantheMan1991/superapp · 2026-08-15
- Move the database off Render's expiring free Postgres to Neon, and back it upradim-zhor/mini-ground-station · 2026-08-03
- feat(infra): migrate Postgres to Neon and object storage to Cloudflare R2AlaskanTuna/SolarSim · 2026-07-30
- fix(db): migrate off Neon (402 quota) to DO Managed PostgresCitrateNetwork/citrate-explorer · 2026-09-30
- Switch local DB setup from Neon to Docker Compose Postgreshenrilhos/compasso · 2026-09-21
- infra: migrate production database from Neon to Railway Postgreskayibabe/qwantej · 2026-09-19
- Switch DB client from Neon HTTP to postgres.js for Supabasedoommir/novapath-website · 2026-09-10
- fix(ops): bump backup-neon to postgres:18-alpine, add pipefailj00su3/DMC_Proyecto · 2026-09-05
- Migrate database from Neon to self-hosted Postgres on k3sLeadKitchen/platform · 2026-09-04
- Migrate database connectivity from Neon to PlanetScale PostgresRocktown-Labs/chewbuu · 2026-08-24
- Migrate analytics DB from Neon to Railway Postgresckrohg/a2w-control · 2026-08-23
- docs(plan): move Postgres off Neon to Render Postgres (Plan 26)hh2110/thandkoi-clinics · 2026-08-17
- feat(db): move off the Neon driver to plain Postgresbeydemirfurkan/todox · 2026-08-15
What makers say
Makers on using it for database, from Product Hunt and Starter Story interviews, each linked to the source. Products with a page of their own and fuller notes first.
Serverless Postgres with branching is a game changer for solo builders. Scale to zero means no idle costs, and the connection pooling just works. Perfect for an early-stage product.
Neon has been great for managing our database. The branching workflow and serverless Postgres made development smooth and allowed me to iterate quickly while building UseAgents.
We use Neon for Superset's Postgres database and database branches when developing schema changes. It is part of the shared backend behind our desktop and mobile apps.
Postgres is rock-solid. It handles complex data relationships gracefully and gives us the querying power we need as we scale. For relational data, it’s hands down the best choice for us.
We picked PostgreSQL over MongoDB and dedicated vector databases because one proven database handles our relational data, JSON and agent memory, with no extra stores to run.
Postgres is so nice to work with. pg_dump was a lifesaver when we had to move database providers. Extensions like pgvector make it the best database for building AI apps.
Loved and watch-outs
Themes that recur in makers' words and Hacker News comments, each linked to what it summarises.
- Postgres scales to zero when idle, so early products and staging databases cost almost nothing until traffic arrives. PHHN
- Branching copies the production database in seconds, so migrations and preview environments are tested against real data. PHPH 2HNHN 2
- The serverless HTTP and WebSocket driver fits Cloudflare Workers and Next.js routes without connection-pool trouble. PHHN
- Separating compute from storage costs latency and performance compared with Postgres on local NVMe. HNHN 2
- Parts of the stack, like autoscaling and some tooling, are not supported or openly licensed for self-hosting. HNHN 2
- With no built-in caching, crawler traffic can burn through the data transfer allowance quickly. HN
- It is rock-solid, keeps data consistent with strong transactions, and handles complex relational queries well. PHPH 2PH 3PH 4
- With pgvector, embeddings live next to relational data, so AI features need no separate vector database. PHPH 2PH 3PH 4
- Extensions and features like PostGIS, JSON support and advanced indexing cover geospatial and semi-structured data too. PHPH 2PH 3
- Built-in full-text search lacks corpus-wide relevance ranking like BM25 and can need very large indexes. HNHN 2
- It has no loose index scan, so SELECT DISTINCT over large tables needs manual workarounds. HNHN 2
- Timestamp versus timestamptz and AT TIME ZONE behavior are easy to get wrong, with edge-case bugs around daylight saving. HNHN 2HN 3

