HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
neondatabase
neon
Rust2022–2026
neondatabase / neon

neon

Neon: Serverless Postgres. We separated storage and compute to offer autoscaling, code-like database branching, and scale to zero.

33Distinct people
38Mentions
0Explicit recommenders
23.3KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Neon: Serverless Postgres. We separated storage and compute to offer autoscaling, code-like database branching, and scale to zero.

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year38 dated mentions

Observed mentions: 2022-05-18 05:13:24 UTC to 2026-01-10 20:17:48 UTC.

0510152022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 15 mentions; 2 submissions, 13 comments20222023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 6 mentions; 0 submissions, 6 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 12 mentions; 2 submissions, 10 comments20242025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC15213
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC606
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC12210
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC404
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC110

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
Neon Neon is an open-source serverless Postgres database platform. It separates storage and compute and substitutes the PostgreSQL storage layer by redistributing data across a cluster of nodes. Quick start Try the Neon Free Tier to create a serverless Postgres instance. Then connect to it with your preferred Postgres client (psql, dbeaver, etc) or use the online SQL Editor. See Connect from any application for connection instructions. Alternatively, compile and run the project locally. Architecture overview A Neon installation consists of compute nodes and the Neon storage engine. Compute nodes are stateless PostgreSQL nodes backed by the Neon storage engine. The Neon storage engine consists of two major components: Pageserver: Scalable storage backend for the compute nodes. Safekeepers: The safekeepers form a redundant WAL service that received WAL from the compute node, and stores it durably until it has been processed by the pageserver and uploaded to cloud storage. See developer documentation in SUMMARY.md for more information. Running a local development environment Neon can be run on a workstation for small experiments and to test code changes, by following these instructions. Installing dependencies on Linux Install build dependencies and other applicable packages On Ubuntu or Debian, this set of packages should be sufficient to build the code: apt install build-essential libtool libreadline-dev zlib1g-dev flex bison libseccomp-dev \ libssl-dev clang pkg-config libpq-dev cmake postgresql-client protobuf-compiler \ libprotobuf-dev libcurl4-openssl-dev openssl python3-poetry lsof libicu-dev On Fedora, these packages are needed: dnf install flex bison readline-devel zlib-devel openssl-devel \ libseccomp-devel perl clang cmake postgresql postgresql-contrib protobuf-compiler \ protobuf-devel libcurl-devel openssl poetry lsof libicu-devel libpq-devel python3-devel \ libffi-devel On Arch based systems, these packages are needed: pacman -S base-devel readline zlib libseccomp openssl clang \ postgresql-libs cmake postgresql protobuf curl lsof Building Neon requires 3.15+ version of protoc (protobuf-compiler). If your distribution provides an older version, you can install a newer version from here. Install Rust # recommended approach from https://www.rust-lang.org/tools/install curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh Installing dependencies on macOS (12.3.1) Install XCode and dependencies xcode-select --install brew install protobuf openssl flex bison icu4c pkg-config m4 # add openssl to PATH, required for ed25519 keys generation in neon_local echo 'export PATH="$(brew --prefix openssl)/bin:$PATH"' >> ~/.zshrc If you get errors about missing m4 you may have to install it manually: brew install m4 brew link --force m4 Install Rust # recommended approach from https://www.rust-lang.org/tools/install curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh Install PostgreSQL Client # from https://stackoverflow.com/questions/44654216/correct-way-to-install-psql-without-full-postgres-on-macos brew install libpq brew link --force libpq Rustc version The project uses rust toolchain file to define the version it's built with in CI for testing and local builds. This file is automatically picked up by rustup that installs (if absent) and uses the toolchain version pinned in the file. rustup users who want to build with another toolchain can use the rustup override command to set a specific toolchain for the project's directory. non-rustup users most probably are not getting the same toolchain automatically from the file, so are responsible to manually verify that their toolchain matches the version in the file. Newer rustc versions most probably will work fine, yet older ones might not be supported due to some new features used by the project or the crates. Building on Linux Build neon and patched postgres # Note: The path to the neon sources can not contain a space. git clone --recursive https://github.com/neondatabase/neon.git cd neon # The preferred and default is to make a debug build. This will create a # demonstrably slower build than a release build. For a release build, # use "BUILD_TYPE=release make -j`nproc` -s" # Remove -s for the verbose build log make -j`nproc` -s Building on OSX Build neon and patched postgres # Note: The path to the neon sources can not contain a space. git clone --recursive https://github.com/neondatabase/neon.git cd neon # The preferred and default is to make a debug build. This will create a # demonstrably slower build than a release build. For a release build, # use "BUILD_TYPE=release make -j`sysctl -n hw.logicalcpu` -s" # Remove -s for the verbose build log make -j`sysctl -n hw.logicalcpu` -s Dependency installation notes To run the psql client, install the postgresql-client package or modify PATH and LD_LIBRARY_PATH to include pg_install/bin and pg_install/lib, respectively. To run the integration tests or Python scripts (not required to use the code), install Python (3.11 or higher), and install the python3 packages using ./scripts/pysync (requires poetry>=1.8) in the project directory. Running neon database Start pageserver and postgres on top of it (should be called from repo root): # Create repository in .neon with proper paths to binaries and data # Later that would be responsibility of a package install script > cargo neon init Initializing pageserver node 1 at '127.0.0.1:64000' in ".neon" # start pageserver, safekeeper, and broker for their intercommunication > cargo neon start Starting neon broker at 127.0.0.1:50051. storage_broker started, pid: 2918372 Starting pageserver node 1 at '127.0.0.1:64000' in ".neon". pageserver started, pid: 2918386 Starting safekeeper at '127.0.0.1:5454' in '.neon/safekeepers/sk1'. safekeeper 1 started, pid: 2918437 # create initial tenant and use it as a default for every future neon_local invocation > cargo neon tenant create --set-default tenant 9
Read the full README on GitHub

What Hacker News says

38 sources
> I assume you're thinking of using FoundationDB as a page store, much like https://github.com/neondatabase/neon uses S3? Actually not, I'm replacing Postres storage entirely down to the tuple level with FoundationDB instead. Neon is really cool but you would lose out on the greatest part of FDB, the transaction processing, if you were to simply use it as a page store (S3 and friends is probably a better fit for something like that). > If not, and you're trying to go more directly for FDB-KV, I hope you're aware of https://www.voltactivedata.com/blog/2015/04/foundationdbs-le... Hadn't seen that before, thanks for linking! Remains to be seen how well I can get this to work although one interesting thing to note is that CockroachDB (which would be the closest thing to what I'm building) is also built on top of a distributed KV store, althou
Read the rest
gh one built into Cockroach. > I'm writing a Postgres-wire-protocol-compatible OLTP database in Rust, using RocksDB for storage as a starting point (MVCC for free!), worrying right now more about correctness and test coverage than performance. But I definitely feel their point of wanting more granular locking at some point. Same at the moment in terms of what to focus on! What excites me the most about my project is the idea of making actual Postgres become seamlessly fully distributed, like Cockroach but not just Postgres-compatible. Would love to hear more about your project, have you published anything on it?
In Ask HN: What are you working on (September 2024)?
I assume you're thinking of using FoundationDB as a page store, much like https://github.com/neondatabase/neon uses S3? If not, and you're trying to go more directly for FDB-KV, I hope you're aware of https://www.voltactivedata.com/blog/2015/04/foundationdbs-le... I'm writing a Postgres-wire-protocol-compatible OLTP database in Rust, using RocksDB for storage as a starting point (MVCC for free!), worrying right now more about correctness and test coverage than performance. But I definitely feel their point of wanting more granular locking at some point.
In Ask HN: What are you working on (September 2024)?
I've been using https://neon.tech in production at Devlog https://dev.log.xyz for the last few months, really quite happy with the pricing and the performance. Clearly made by and for developers. The only surprise I had was that they don't show you any database logs! Turns out I haven't needed this so it's not a big deal, but that's the biggest departure from a "traditional hosted postgres" service. Aside from that, the only missing feature is the ability to create an Organization rather than hosting projects in a personally-affiliated account, but this is apparently coming soon. The branching features work really well and I've used it a few times now to debug issues and test migrations without impacting production. I haven't set up the per-pull-request-preview-environment stuff yet but I plan to and I like that Neon makes it easy. EDIT:
Read the rest
oh, the one other annoyance is that last time I checked, it was not possible to create a read-only replica in a different region than the primary compute node. Or something like that, I'm still not sure, and multi-region read replicas are not particularly necessary for me right now (Devlog still in early alpha, not a lot of customers) so I just moved on. Issue tracked here https://github.com/neondatabase/neon/issues/4178
In Neon: A serverless open-source alternative to AWS Aurora Postgres
what was bizarre in this article. I found it's a simple customer success story about Neon but I see the improvement came from caching and connection pooling but Neon looks promising because of its database branching feature, which made testing and development faster looks like Neon(https://github.com/neondatabase/neon) seems to have helped them with testing and development. Being able to iterate and validate changes is a great benefit.
In Our great database migration
I want to use this as a chance to bring attention to a GitHub issue that I think would help reduce friction for Neon: https://github.com/neondatabase/neon/issues/4989 If the Neon driver were to allow us to easily pass in a localhost connection, the development and test experience would be easier. Perhaps Neon could swap to something like this internally: https://github.com/porsager/postgres. Having run a local dev environment connected to Neon and tests connected to Neon got in our way of adoption. We'd prefer to develop and run tests against a regular Postgres localhost database. To the PMs of Neon, put yourself in the shoes of a new developer thinking of giving Neon a try. What changes will I have to make to my code and my development workflow?
In Neon Serverless Postgres is generally available
In the linked article it says: "Unlike AWS Aurora we decided to open source all the changes in Postgres and also send them upstream as well as fully open source our cloud native storage." Also, at the top right there's a link to the GitHub repo: https://github.com/neondatabase/neon You can find replies from folks in this thread as well discussing self hosted deployments and you can find an entire discord channel dedicated to that topic here: https://discord.gg/92vNTzKDGp I'm not associated with Neon and I've never used it before and I certainly don't disagree with your sentiment, but it seems like Neon has gone above and beyond in making sure that workloads could continue to run in the event the company fails and broadly assuaging those concerns.
In Neon Serverless Postgres is generally available
Cool! At Neon[0], I work full time on our custom postgres proxy[1]. It's a very nice protocol to work with, although our usecase is quite a bit more complex compared to the ideas presented in the post. Neon databases scale to zero, so the proxy needs to spin up databases on the fly. The proxy doesn't do that but it knows if the databases is running and asks our control plane to schedule it if it isn't. It's a fun service to maintain. The biggest pain is error handling. Postgres is really bad for error messages and codes. The only available code we can use is usually protocol violation... [0]: https://neon.tech/ [1]: https://github.com/neondatabase/neon/tree/main/proxy
In Parsing the Postgres protocol – logging executed statements

Showing the 15 most recent of 38 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.