rcrowley

6 ms·

1.
by rcrowley 6d ago
It felt rude to take so many r8gd instances away from our customers who really love those (and i8g and i8ge).
2.
by rcrowley 9mo ago
Yes, you can certainly use up your CPU allocation on an M-10 database (at which point we offer online resizing as large as you want to go, all the way up to 192 CPUs and 1.5TiB RAM). Even still, I've been able to coax more than 10,000
3.
by rcrowley 9mo ago
This will be faster than an equivalent RDS instance and will handle more of the operational lifecycle around failover and high-availability with less downtime than RDS.
4.
by rcrowley 9mo ago
Within PlanetScale's product lineup, Metal refers to the use of local NVMe drives. Nothing more. These extremely affordable sizes are indeed slices of larger boxen, though no resources are overcommitted.
5.
by rcrowley 9mo ago
Soon!
6.
by rcrowley 9mo ago
These are all three-node clusters with PlanetScale's management handling backup, restore, failover, and replication.
7.
by rcrowley 9mo ago
PlanetScale's Postgres offering is as close to plain-old-Postgres as we could possibly build.
8.
by rcrowley 9mo ago
We run on the same instance types the larger PlanetScale Metal sizes offer as whole instances. For Intel that's r6id, i4i, i7i, i3en, and i7ie. For ARM that's r8gd, i8g, and i8ge. (Right now, at least. AWS is always cookin' u
9.
by rcrowley 9mo ago
We've engineered in protections from noisy neighbors in both CPU and I/O usage and we do not over-commit resources. If your or another customer's workload grows and needs to size up we launch three whole new database servers
10.
by rcrowley 9mo ago
PlanetScale operates databases in AWS and GCP. There's no network latency penalty for choosing PlanetScale if you're hosting your app in one of those cloud providers (and in one of the many regions we operate in).
11.
by rcrowley 9mo ago
Correct you are. Just want to add that you don't necessarily need to invest in fancy disk-usage monitoring as we always display it in the app and we start emailing database owners at 60% full to make sure no one misses it.
12.
by rcrowley 11mo ago
RAID isn't the answer, either, for the record. In AWS and GCP, the CPU or RAM blowing up will cost you access to that local NVMe drive, too, no matter how much RAID you throw at it.
13.
by rcrowley 11mo ago
Yes, a single disk in a VPS or cloud provider has durability concerns. That's why EBS and products like it that pretend to be a single disk are actually several. Instead of relying on multiple block devices, though, we create that redu
14.
by rcrowley 1y ago
The question isn't how many orphaned rows do you have, it's whether it matters. Databases are wonderful but they cannot maintain every invariant and they cannot express a whole application. They're one tool in the belt.
15.
by rcrowley 1y ago
I computed P(node failure within MTTR) = 0.00007 same as you. I extrapolated this to the outage scenario P(at least two node failures within MTTR) = P(node failure within MTTR)^2 * (1-P(node failure within MTTR)) + P(node failure within MTT
16.
by rcrowley 1y ago
The short answer is that RDS doesn't run on local NVMe disks, it runs on EBS.
17.
by rcrowley 1y ago
A lagging replica, even one that just acknowledged a semi-sync write, will return stale results if you route a `SELECT` to it. First and foremost, the extra copies of the data are for fault tolerance. In specific circumstances they may offe
18.
by rcrowley 1y ago
I think we've got (1) covered elsewhere in the comment tree. For (2), semi-synchronous replication is a MySQL term which we realize in Postgres is by using synchronous replication with ANY one of the available replicas acknowledging th
19.
by rcrowley 1y ago
Good point, Max. I glossed over the "rather than" bit. We do, as you say, write to disks all over the place. Even writing to one disk, though, isn't good enough. So we write to three and wait until two have acknowledged befor
20.
by rcrowley 1y ago
1. I don't know if there's a single name for this. I will point out that AWS EBS and Google Persistent Disk as industrial examples of distributed, replicated block devices are also providing durability via replication. They'r
21.
by rcrowley 1y ago
Fair to say 500GB is small, especially compared to some of the folks who've already migrated, but do note that it's 15x RAM on the benchmark machines, so we really were testing the whole database and not just the memory bandwidth
22.
by rcrowley 1y ago
You don't (typically) lose the data on the ephemeral drive across a reboot but you definitely can (and do!) when there are more permanent hardware failures. (They really happen!) That's why PlanetScale always maintains at least th
23.
by rcrowley 1y ago
PlanetScale always maintains three (or more, if you want) copies of the data and only acknowledges writes after they've been written to at least two cloud provider availability zones. Durability is provided via replication at the datab
24.
by rcrowley 1y ago
All our list prices are monthly and our bills are actually even finer-grained - there's no commitment to pay for a database longer than you run it. If you do decide to operate on PlanetScale long-term, check out < https://
25.
by rcrowley 1y ago
Many! < https://planetscale.com/docs/postgres/extensions >
26.
by rcrowley 2y ago
AWS, for one example, provide a feed of upcoming "events" in EC2 in which certain instances will need to be rebooted or terminated entirely due to whatever maintenance they're doing on the physical infrastructure. If you miss
27.
by rcrowley 2y ago
Good points. PlanetScale's durability and reliability are built on replication - MySQL replication - and all the operational software we've written to maintain replication in the face of servers coming and going, network partition
28.
by rcrowley 2y ago
Neat workaround! We only started working with GCP Local SSDs in 2024 and can report we haven't experienced read or write failures due to bad sectors in any of our testing. That said, we're running a redundant system in which MySQL
29.
by rcrowley 2y ago
Glad to find a kindred spirit. I proposed PlanetScale Metal (though our CEO Sam gets credit for the name) based on how we ran MySQL and Vitess at Slack for many, many years. We earn our durability through MySQL replication and redundancy an
30.
Nebula is Not the Fastest Mesh VPN (But neither are any of the others)(defined.net)
13 points by rcrowley 3y ago|1 comments

More ›