91–100 of 196 posts
Not a single explanation of what ‘PlanetScale’ is, does (or how) on that landing page. A product, a service, a new offering or scaling paradigm, a cloud? Etc Sure you can click around to determine but this always annoys me. Like everyone should know what your product is and does and all you service names. Put it front and center at the top!
The elephant in the room is you cant use FKs when you go planetscale. This has a huge impact on how you design your database.
Earlier quoted context omitted.
How should one decide whether to go with MySQL or Postgres for a greenfield project?
At this point I'm not sure why anyone would choose MySQL. Any advantage it had pretty much evaporated with these hosted solutions. For example, MySQL was easier to get running and connect to. These cloud offerings (Planetscale, Supabase, Neon, even RDS) have solved that. MySQL was faster for read heavy loads. Also solved by the cloud vendors.
Because I have used MySQL for over 20 years and it is what I know!
Earlier quoted context omitted.
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 three copies of the data. We guarantee durability via replication, not by trusting the (slow, network-attached) block device. I did an interview all about PlanetScale Metal a couple of months…
Hi, thank you for your work on this and being willing to answer questions on it. "We guarantee durability via replication". I've starting noticing this pattern more where distributed systems provide durability by replicating data rather than writing it to disk and achieving the best of both worlds. I'm curious 1. Is there a name for this technique? 2. How do you calculate your availability? This blog post[1] has some…
Earlier quoted context omitted.
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 three copies of the data. We guarantee durability via replication, not by trusting the (slow, network-attached) block device. I did an interview all about PlanetScale Metal a couple of months…
Hi, thank you for your work on this and being willing to answer questions on it. "We guarantee durability via replication". I've starting noticing this pattern more where distributed systems provide durability by replicating data rather than writing it to disk and achieving the best of both worlds. I'm curious 1. Is there a name for this technique? 2. How do you calculate your availability? This blog post[1] has some…
2. The thinking laid out in the blog post you linked to is how we went about it. You can do the math with your own parameters by computing the probability of a second node failure within the time it takes to recover from a first node failure. These are independent failures, being on physically separate hardware in physically separate availability zones. It's only when they happen together that problems arise. The core is this: P(second node failure within MTTR for first node failure) = 1 - e^( -(MTTR node failure) / (MTBF for a node) )
3. This one's harder to test yourself. You can do all sorts of tests yourself (https://rcrowley.org/2019/disasterpiece-theater.html>) and via AWS FIS but you kind of have to trust the cloud provider (or read their SOC 2 report) to learn how availability zones really work and really fail.
Earlier quoted context omitted.
i'll take the opposite side. i was very impressed with their website. the very first line: > The world’s fastest and most scalable cloud databases the second line: > PlanetScale brings you the fastest databases available in the cloud. Both our Postgres and Vitess databases deliver exceptional speed and reliability, with Vitess adding ultra scalability through horizontal sharding. i know exactly what they do. zero flu…
How is this different than Aurora Postgres or RDS Postgres?
Earlier quoted context omitted.
Hi, thank you for your work on this and being willing to answer questions on it. "We guarantee durability via replication". I've starting noticing this pattern more where distributed systems provide durability by replicating data rather than writing it to disk and achieving the best of both worlds. I'm curious 1. Is there a name for this technique? 2. How do you calculate your availability? This blog post[1] has some…
Hi n_u, PlanetScale engineer here, I'm going to just address just the point about durability via replication. I can't speak to what you've seen with other distributed systems, but, at PlanetScale, we don't do replication instead of writing to disk, we do replication in addition to writing to disk. Best of both worlds.
Even writing to one disk, though, isn't good enough. So we write to three and wait until two have acknowledged before we acknowledge that write to the client.
Earlier quoted context omitted.
hosting on AWS/GCP on the ephemeral NVMe nodes. https://planetscale.com/metal
A couple dumb questions: 1. You say "ephemeral", but my understanding is that NVMe is non-volatile so upon crash and restart we should be able to recover the state of the memory. Is is ephemeral because of how EC2 works where you might not get that same physical box and memory addresses back? 2. Can you explain what "Semi-synchronous replication" is? Your docs say "This ensures every write has reached stable storage…
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 the write. This allows us to guarantee durability in two availability zones before acknowledging writes to clients.
In MySQL the _semi_ part of semi-synchronous replication refers to the write only needing to be written to the binary log on the replica and not (necessarily) applied to InnoDB. This is why a MySQL database might be both acknowledging semi-synchronous writes and reporting non-zero replication lag.