I am not experienced enough to know the performance differences between planetscale and supabase, but...
> It's designed for businesses that need to haul ass
Could you elaborate what you meant by this for my education?
> It's designed for businesses that need to haul ass
Could you elaborate what you meant by this for my education?
> Benchmarks are done on a dual-core VM with "unlimited" IOPS
I'd be interested in a comparison with a pair of Beelink SER5 Pros ($300 each) in master-slave config.
Unlimited is a feature here, no need to be snarky. They famously went against the accepted practice of separating storage from compute, and as a result, you reduce latency by an order of magnitude and get unlimited IOPS.
That might not be 100% true, but I've never seen a RDBMS be able to saturate IOPS on a local NVMe. It's some quite specialized software to leverage every ounce of IOPS without being CPU bottlenecked first. Postgres and MySQL are not it.
Anyway, saying unlimited is absurd. If you think it's more than you need, say how much it is and say that's more than you need. If you have infinite IOPS why not do the benchmark on a dataset that fits in CPU cache?
Not all AWS instance types support NVMe drives. It's not the same as normal attached storage.
I'm not really sure your arguments are in good faith here tho.
This is just not a configuration you can trivially do while maintaining durability and HA.
There's a lot of hype going the exact opposite direction and more separation of storage and compute. This is our counter to that. We think even EBS is bad.
This isn't a setup that is naturally just going to beat a "real server" that also has local NVMes or whatever you'd do yourself. This is just not what things like RDS or Aurora do, etc. Most things rely on EBS which is significantly worse than local storages. We aren't really claiming we've invented something new here. It's just unique in the managed database space.
I agree that EBS and the defaults RDS tries to push you into are awful for a database in any case. 3k IOPS or something absurd like that. But that's kind of the point: AWS sells that as "SSD" storage. Sure it's SSD, but it's also 100-1000x slower than the SSDs most devs would think of. Their local "NVMe" is AFAIK also way slower than what it's meant to evoke in your mind unless you're getting the largest instances.
Actually, showing scaling behavior with large instances might make Planetscale look even better than competitors in AWS if you can scale further vertically before needing to go horizontal.
Even if you can't saturate them, even with low CPU cores, latency is drastically better which is highly important for database performance.
Having low latency is tangibly more important than throughput or number of IOPS once your dataset is larger than RAM no matter how many CPU cores you have.
Chasing down p95s and above really shine with NVMes purely from having whatever order of magnitude less latency.
Less latency also equates to less iowait time. All of this just leads to better CPU time utilization on your database.
Yes there are benefits like lower latency, which is often measured in terms of qd1 IOPS.
> Unlimited I/O — Metal's local NVMe drives offer higher I/O bandwidth than network-attached storage. You will run out of CPU long before you use all your I/O bandwidth.
Our uptime and reliability is also higher than what you might find elsewhere. It's not uncommon for companies paying lots of money to operate elsewhere to migrate to PlanetScale for that reason.
We're a serious database for serious businesses. If a business can't afford to spend $39/mo to try PlanetScale, they may be happier operating elsewhere until their business grows to a point where they are running into scaling and performance limits and can afford (or badly need, depending on the severity of those limits) to try us out.