This doesn’t seem to provide higher write availability, and if the read replicas are consistent with the write replica this design must surely degrade write availability as it improves read availability, since the write replica must update all the read replicas.
This also doesn’t appear to describe a higher durability design at all by normal definitions (in the context of databases at least) if it’s async…?
I think you may have misunderstood the GP and are perhaps misusing terminology. You cannot meaningfully scale vertically to improve write availability, and if you care about availability a single machine (and often a primary/secondary setup) is insufficient.
Even if you only care about scaling reads, eventually the 1:N write:read replica ratio will become too costly to maintain, and long before you reach that point you likely sacrifice real-time isolation guarantees to maintain your write availability and throughput.
> You cannot meaningfully scale vertically to improve write availability
Disagree. Even if you limit yourself to the cloud, r7i/r8g.48xl gets you 192 vCPU / 1.5 TiB RAM. If you really want to get silly, x2iedn.32xl is 128 vCPU / 4 TiB RAM, and you get 3.8 TiB of local NVMe storage for temp tablespace. The money you’ll pay ($16.5K - $44K month, depending on specific class) would pay for a similarly spec’d server in the same amount of time, though.
Which brings me to the novel concept of owning your own hardware. A quick look at Supermicro’s site shows a 2U w/ up to 1.92 PB of Gen5 NVMe, 8 TiB of RAM, and dual sockets. That would likely cost a wee bit more than a month of renting the aforementioned AWS VM, but a more reasonably spec’d one would not. Realistically, that much storage would be used as SDS for other DBs to use. NVMoF isn’t quite as fast as local disks, but it’s a hell of a lot faster than EBS et al.
The point is that you actually can vertically scale to stupidly high levels, it’s just that most companies have no idea how to run servers anymore.
> and if you care about availability a single machine (and often a primary/secondary setup) is insufficient.
Depending on your availability SLOs, of course, I think you’d find that a two-node setup (optionally having N read replicas) with one in standby would be quite sufficient. Speaking from personal experience on RDS (MySQL fronted with ProxySQL on K8s, load balanced with NLB), I experienced a single outage in two years. When it happened, no one noticed, it was so brief. Some notice-only alerts for 500s in Slack, but no pages went out.
> If you really want to get silly, x2iedn.32xl is 128 vCPU / 4 TiB RAM, and you get 3.8 TiB of local NVMe
This doesn't affect availability - except insofar as unavailability might be caused by insufficient capacity, which is not the typical definition.
> Depending on your availability SLOs, of course
Yes, exactly. Which is the point the GP was making. You generally make the trade-off in question not for performance, but because you have SLOs demanding higher availability. If you do not have these SLOs, then of course you don't want to make that trade-off.
The big caveat about these configurations is the amount of time it takes to rebuild a replica due to the quantity of storage per node that has to be pushed over the network. This is one of the low-key major advantages of disaggregated storage.
I prefer to design my own hardware infrastructure but there are many operational tradeoffs to consider.
> you likely sacrifice real-time isolation guarantees to maintain your write availability and throughput
No worries there, in all likelihood isolation has probably been killed twice already. Once by running the DB on READ COMMITTED, and a second time by using an ORM like EF to read data into your application, fiddle with it in-RAM, and write the new (unrelated-to-what-was-read) data back to the DB.
In other words, we throw out all that performant 2010-2020 NoSQL & eventual consistency tech, and go back to good old fashioned SQL & ACID, because everyone knows SQL, and ACID is amazing. Then we use LINQ/EF instead because it turns out that no-one actually wants to touch SQL, and full isolation is too slow so that gets axed too.
No loss of committed transactions is acceptable to any serious business.
>I work at Neon
In my opinion, distributed DB solutions without synchronous write replication are DOA. Apparently a good number of people don't share this opinion because there's a whole cottage industry around such solutions, but I would never touch them with a 10 foot stick.
Hey everyone, I'm an engineer at Neon and I wanted to share this FAQ which covers a lot of the questions that are being brought up in the comments here:
For what it's worth the questions can't really be answered by a simple FAQ, because history has shown that those answers aren't worth the page they're written on. Many companies that get bought talk all about the fact that nothing is going to change.
Something is always going to change, almost always in a way that impacts customers. In the best case it's something simple like a different name on the bill, other times it will leave customers scrambling for an alternative before a ridiculous deadline. It could happen within weeks, after a month, or it might take a year. The answers at the time of the announcement are the same regardless.
That’s a nice FAQ and all but after what happened to bit.io [0] you have to understand why people (like me) are extremely worried about this.
We’ve all read glowing blog posts and reassuring FAQs enough times after an acquisition only to see a
complete about-face a few months or a year later.
I quite enjoyed using Neon but as a solo founder running my business on Neon I can’t help but think it’s insanity to not be looking for alternatives.
Databricks is _not_ a company I trust at all.
[0] if you don’t know, databricks acquired bit.io and shut down all databases within 30 days. Production databases had <30 days to migrate.
Love Neon, but that FAQ is worthless. Every company that gets acquired reassures customers that "nothing will change"... then it does, once the new company is in the acquirer's belly and gets digested.
Neon — Ship Faster with Postgres (https://neon.tech) | Remote | Full Time
Neon is a distributed team building an open-source, cloud-native Postgres platform. We are a well-funded startup with deep knowledge of Postgres internals and decades of experience building databases. Our storage layer is written in Rust, and our cloud control plane is written in Go. We are on a mission to enable developers to “Ship faster with Postgres”. We are hiring for:
* Product Engineer to work on the UI/UX for an agent. Experience with full-stack development and AI is required.
If you want to learn more about the engineering work we do, check out some of these blog posts:
> If performance matters, some migrations might hide table locks which can cause major slowdowns.
Do you mean that the migration might work on a side branch, but then it might not work on the main branch, because there's no other activity running on the side branch?
Neon — Ship Faster with Postgres (https://neon.tech) | Remote | Full Time
Neon is distributed team building open-source, cloud-native Postgres. We are a well-funded startup with deep knowledge of Postgres internals and decades of experience building databases. Our storage layer is written in Rust, and our cloud control plane is written in Go. We are on a mission to enable developers to “Ship faster with Postgres”.
* Team Lead, Backend as a Service (7+ years experience, ideally in and around dev tooling, cloud infra and full-stack app development)
If you want to learn more about the engineering work we do, check out some of these blog posts:
The 15 seconds start up time limits the utility for production workloads indeed, specifically for multi-tenant apps looking to provide very strong per-tenant isolation. If you need Instant Postgres, check out Neon: https://neon.tech/demos/instant-postgres.
Ha, I was just reading your blog post on running next.js on cloudflare. It made me seriously consider remix as an alternative. I'll take this comment that remix is the way to go. I'm also working on a small webapp like the one you built
- Availability: spin up more read replicas.
- Durability: spin up more read replicas and also write to S3 asynchronously.
With Postgres on Neon, you can have both of these very easily. Same with Aurora.
(Disclaimer: I work at Neon)