I think this is confusing Planetscale's primary objective: to make it incredibly easy and efficient to scale a database up and out.
There's no mention of sharding whatsoever. Without that this has very little to do with Planetscale and is much closer to your average managed DB (RDS etc.). There's also no mention of a bouncer/gateway/reverse proxy, which is necessary for zero downtime.
I get that Planetscale hosts "vanilla" Postgres instances but naturally those are limited by single instance size limits. I imagine this is predominantly a marketing strategy for them, acting as a funnel for their sharding products.
But perhaps that's the goal with this project, to not be Planetscale at all, and to focus on the single node. If that's the case, then great, best of luck, but the roadmap is missing some important pieces for me to take this seriously. In either case I find drawing comparison with Planetscale to not be very helpful or illustrative of the project and its goals.
Most cloud SaaS is trivial to build and run locally. Many of it is just hosted versions of what already exists.
It's like when people "build our own redis from scratch" - not a feat worth bragging about, if you hosted a high availability memory cache for apps that might be something worth sharing, but the tech is nothing.
OP's interview with the F1 team sounds super cool, I'd actually love to hear more about their experience and the vibes they got from potentially working a dev job for a sports team. I had a close encounter with the analytics department of an MLB Team not too long ago and found that pocket of the tech world beyond fascinating. I just wish I had more exposure to the folks working in it.
A few of us built nearly the exact same thing for a Hackathon which was fun. This definitely can work. There are a couple of other approaches too that are interesting like
- xata - https://xata.io/blog/xatastor-zfs-nvme-of-for-millions-of-postgres-databases
- neon - which has a more sophisticated architecture that builds abstractions at the Postgres layer
But separating compute and storage sucks and the performance you get out of EBS and friends is mediocre. The elasticity is nice, but if you have High Availability and can move instances around, you can still expand your cluster relatively easily, just not easily in an emergency scenario.
Because you mentioned Xata (I'm the author of that blog post, thanks for mentioning it), this is pretty similar to what we do at the high level, but we built our own storage system rather than relying on Ceph. The reason is scalability to many volumes and to lesser degree performance.
I'd say Homescale is closer to Xata than Planetscale, tbh :)
I haven’t put too much thought into this yet. A "branch" depth threshold is the first thing that comes to mind, with RBD flattening as an option once that threshold is reached.
You did the easy part. Now do the managed database part, and at scale, whereby I don't have to worry about any chance of data loss. Otherwise this isn't "building PlanetScale" - it's building 1/100th of it.
It annoys me when people claim they've "easily and quickly" built something that took many developers many months or years worth of work and optimization to build a solid product.
It's like someone who generates a pretty looking HTML page with an LLM and claims they've built a customer-facing product. So much slop these days...
I am not sure where you think I claimed it'll be "easy and quick". Do you really think building a system on top of k8s internals and Ceph is something that everybody can pull off?.
It's far from complete. This is just the infrastructure bit that I need to build the actual service. I am going to build an operator, a coordinator, an API and a CLI. I am going to continue writing posts while building them.
I think this is confusing Planetscale's primary objective: to make it incredibly easy and efficient to scale a database up and out.
There's no mention of sharding whatsoever. Without that this has very little to do with Planetscale and is much closer to your average managed DB (RDS etc.). There's also no mention of a bouncer/gateway/reverse proxy, which is necessary for zero downtime.
I get that Planetscale hosts "vanilla" Postgres instances but naturally those are limited by single instance size limits. I imagine this is predominantly a marketing strategy for them, acting as a funnel for their sharding products.
But perhaps that's the goal with this project, to not be Planetscale at all, and to focus on the single node. If that's the case, then great, best of luck, but the roadmap is missing some important pieces for me to take this seriously. In either case I find drawing comparison with Planetscale to not be very helpful or illustrative of the project and its goals.
Most cloud SaaS is trivial to build and run locally. Many of it is just hosted versions of what already exists.
It's like when people "build our own redis from scratch" - not a feat worth bragging about, if you hosted a high availability memory cache for apps that might be something worth sharing, but the tech is nothing.
OP's interview with the F1 team sounds super cool, I'd actually love to hear more about their experience and the vibes they got from potentially working a dev job for a sports team. I had a close encounter with the analytics department of an MLB Team not too long ago and found that pocket of the tech world beyond fascinating. I just wish I had more exposure to the folks working in it.
A few of us built nearly the exact same thing for a Hackathon which was fun. This definitely can work. There are a couple of other approaches too that are interesting like
But separating compute and storage sucks and the performance you get out of EBS and friends is mediocre. The elasticity is nice, but if you have High Availability and can move instances around, you can still expand your cluster relatively easily, just not easily in an emergency scenario.Because you mentioned Xata (I'm the author of that blog post, thanks for mentioning it), this is pretty similar to what we do at the high level, but we built our own storage system rather than relying on Ceph. The reason is scalability to many volumes and to lesser degree performance.
I'd say Homescale is closer to Xata than Planetscale, tbh :)
It was a good read. I also worked on a similar product that used zfs instead of Ceph.
Also, as you said, Homescale is a lot closer to Xata. It all started as a joke and the name stuck.
The performance definitely sucks but it's not a really serious project. I wouldn't use something like Homescale for using facing products.
Nice breakdown of the COW model. How do you plan to clean up snapshots once branches get a few generations deep?
I haven’t put too much thought into this yet. A "branch" depth threshold is the first thing that comes to mind, with RBD flattening as an option once that threshold is reached.
You did the easy part. Now do the managed database part, and at scale, whereby I don't have to worry about any chance of data loss. Otherwise this isn't "building PlanetScale" - it's building 1/100th of it.
It annoys me when people claim they've "easily and quickly" built something that took many developers many months or years worth of work and optimization to build a solid product.
It's like someone who generates a pretty looking HTML page with an LLM and claims they've built a customer-facing product. So much slop these days...
I am not sure where you think I claimed it'll be "easy and quick". Do you really think building a system on top of k8s internals and Ceph is something that everybody can pull off?.
Awesome. I've been playing exploring PITR stuff recently in my homelab. Will give it a go and try to contribute if I spot any issues
It's far from complete. This is just the infrastructure bit that I need to build the actual service. I am going to build an operator, a coordinator, an API and a CLI. I am going to continue writing posts while building them.
Lolz, just forward to my friend who works at Planetscale. Looking forward to his reaction
I hope they'll enjoy reading it.
MoonScale