I'm CEO of Neon. Happy to answer any questions you might have.
I have a number of workloads I'd migrate to you over the next few weeks if you're ready for it. What is the state of Neon?
Is it ready for small-volume but business critical loads?
I'm struggling to find support guarantees and SLAs on your website, do you have them yet?
What is your off-site backup story? Can I export my backups to something like R2, S3, or B2?
Many of my customers are running in Cloudflare Workers. Their volume is low, but it's business critical (DB downtime means business downtime - business will fail if we lose all the data).
> Is it ready for small-volume but business critical loads? Depends on business criticality. But generally yes. We are debating internally when we are going to announce it.
> I'm struggling to find support guarantees and SLAs on your website, do you have them yet? Good feedback. It's in the works.
> What is your off-site backup story? Can I export my backups to something like R2, S3, or B2? Since our storage is integrated with s3 and supports branching we can treat branches as backups. > Many of my customers are running in Cloudflare Workers. Their volume is low, but it's business critical (DB downtime means business downtime - business will fail if we lose all the data). We haven't lost data yet. There are a lot of redundancy in the system. Safekeepers, S3, branches (backups).
Neon[2] is Postgres that has a surgically enhanced data layer that reads from a distributed set of nodes and object storage, but is still a single Postgres instance that's started and stopped on-demand and not automatically sharded. Because it's real Postgres, all functionality works including extensions without dealing with issues from sharded datasets, but also without the horizontally scalability and instant start (so far). However because the data layer is improved, the actual compute node is much more efficient in both startup and processing so it works well in many scenarios.
CockroachDB[3] is a proprietary distributed database built to Postgres wire/data protocol with natively separated storage and compute. Their serverless plan also starts and stops instances as traffic comes in but with fast startup because of their specific architecture. Because it's not real Postgres though, there's a good bit of missing functionality.
There's also TiDB[4] from PingCap which is similar to a MySQL version of CockroachDB, and Yugabyte[5] which is somewhat like Neon but with both distributed compute and data layers also using real Postgres components - however neither has a serverless offering.
1. https://planetscale.com/ 2. https://neon.tech/ 3. https://www.cockroachlabs.com/ 4. https://www.pingcap.com/tidb/ 5. https://www.yugabyte.com/
This is a good analysis of network time and optimization. I'd love to see a followup exploring the impact on the server side; Considering how Postgres was historically not very efficient at setting up new connections but has been steadily getting better with each major release. It would also be great to see what portion of the request is taken up by the setup versus the query itself, to have some idea of cost.
In that case, do you manage the possibility of multiple clients opening a websocket connection to the same to “the same” server (which may actually be a different instance of the same proxy)
From there we are thinking to expose <project_id>.read.neon.tech and <project_id>.write.neon.tech and for read queries route traffic to the local replica.
It's not set in stone yet, but that's the gist of it.
- Data safety and privacy. As I'm UK based - can my data be restricted to the UK only (no magic round the world trips inside your backend)? do you comply with the GDPR?
- Can I set up postgres (WAL) replication to a non-neon database?