neon
Neon is an open-source serverless PostgreSQL platform that separates storage and compute to enable autoscaling, database branching, and scale-to-zero functionality. Written in Rust, it replaces PostgreSQL's storage layer with a distributed architecture using pageservers and safekeepers for durability.
Key facts
Objective fields from the source. Values we can't verify are shown as “Unknown” rather than guessed.
| Field | Value |
|---|---|
| Repository | neondatabase/neon |
| Owner | neondatabase |
| Primary language | Rust |
| License | Apache-2.0 — OSI-approved |
| Stars | 22.5k |
| Forks | 1k |
| Open issues | 543 |
| Latest release | release-proxy-8853 (2025-07-29) |
| Last updated | 2026-05-25 |
| Source | https://github.com/neondatabase/neon |
What neon is
Neon decouples compute (stateless PostgreSQL nodes) from storage via a custom storage engine with pageserver and safekeeper components. The architecture supports branching via timeline-based versioning, WAL-based replication, and cloud storage integration, maintaining PostgreSQL protocol compatibility.
Get the neon source
Clone the repository and explore it locally.
git clone https://github.com/neondatabase/neon.gitcd neon# follow the project's README for install & configurationNeed it deployed, integrated, or customized instead? DEV.co ships production installs.
Best use cases
Implementation considerations
- Build dependencies are substantial (Rust toolchain, protobuf ≥3.15, libpq, build-essential); Linux/macOS setup requires 15+ packages.
- Local development via `cargo neon` CLI; production deployment complexity unknown—requires review of ops documentation and cloud integration.
- Database branching via timelines is a non-standard PostgreSQL feature; application logic must be evaluated for compatibility.
- Storage backend is distributed (pageserver + safekeeper); operational understanding of WAL redundancy, failover, and recovery is essential.
- Connection pooling and autoscaling triggers are not detailed in excerpt; behavior under load requires testing.
When to avoid it — and what to weigh
- Strict Latency SLAs — Distributed architecture adds complexity; scale-up/down latency and network hops between compute and storage may not meet sub-millisecond requirements.
- Existing PostgreSQL Lock-In — Migration from production PostgreSQL requires data transfer, testing, and validation; not a drop-in replacement for running systems.
- Unsupported PostgreSQL Features — Requires evaluation of exotic extensions, custom types, or older PostgreSQL versions—compatibility not guaranteed beyond core features.
- Fully On-Premise Only — Project includes cloud-storage integration; self-hosted deployments require external object storage (S3, etc.) and operational overhead.
License & commercial use
Apache License 2.0 (Apache-2.0). Permissive OSI-approved license allowing modification, distribution, and private use with attribution and liability disclaimer.
Apache 2.0 permits commercial use. However, Neon is actively developed by Neon (the company); confirm whether commercial deployments are supported by the project or require vendor support. Self-hosted deployments may lack vendor SLAs.
DEV.co evaluation signals
Editorial assessment — not user reviews. Directional, with an explicit confidence level.
| Signal | Assessment |
|---|---|
| Maintenance | Active |
| Documentation | Adequate |
| License clarity | Clear |
| Deployment complexity | Moderate |
| DEV.co fit | Good |
| Assessment confidence | High |
Apache 2.0 license does not imply security guarantees. Review needed: WAL encryption, transport security (TLS), access control, audit logging, and secrets management. No security audit or CVE history provided. Distributed architecture (compute/storage) introduces network security concerns.
Alternatives to consider
AWS Aurora Serverless
Managed serverless PostgreSQL with autoscaling; no self-hosted complexity but vendor lock-in and higher per-unit cost.
PlanetScale (MySQL) / Vitess
Horizontal scaling and branching for MySQL; different database engine but similar serverless/branching model.
Standard PostgreSQL (RDS, managed Postgres)
Simpler, battle-tested, but lacks autoscaling and branching; suitable if serverless features are not required.
Build on neon with DEV.co software developers
Start with Neon's free tier or review deployment docs to assess fit for your infrastructure. Consult a DevOps specialist if on-premises deployment is required.
Talk to DEV.coRelated open-source tools
Surfaced by semantic similarity across the DEV.co open-source index.
Related on DEV.co
Explore the category and the services that help you build with it.
neon FAQ
Is Neon production-ready?
Can I migrate my existing PostgreSQL database to Neon?
Does Neon support replication or failover?
What are the limits on branching or scale-to-zero?
Work with a software development agency
DEV.co helps companies turn open-source tools like neon into production software. Our software development services cover the full lifecycle — architecture, web development, integration, and maintenance — delivered by software developers and web developers who ship. Engage our software development agency to implement or customize it for your open-source databases stack.
Ready to Explore Serverless PostgreSQL?
Start with Neon's free tier or review deployment docs to assess fit for your infrastructure. Consult a DevOps specialist if on-premises deployment is required.