Building Homescale: Creating PlanetScale-Like Infrastructure at Home
Let's Build PlanetScale from Scratch: Infrastructure
I am building Homescale to bring PlanetScale's branching capabilities to home environments. By separating storage from compute and using Ceph's copy-on-write technology, I can create writable database branches from immutable snapshots without duplicating data. This approach allows Postgres and other engines to share storage efficiently, enabling instant cloning and point-in-time recovery through a simple CLI.
A branch of a 100 GB database therefore appears as a complete 100 GB database without requiring another 100 GB copy up front.
- xyzzy_plugh
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.
- maherbeg
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.
- xolox
The conceptual relationship to PlanetScale seems somewhat dubious to me (as mentioned in other comments) but the idea of implementing snapshots and branching below the database server level, in the storage layer using Ceph, is neat and potentially quite elegant! Kudos for that idea :-). I hope implementing it works out to the same elegant API envisioned in the initial concept. I could see this being very useful in a development workflow like the example (dev-db/feature-login).
I have to say that my experiences with running virtualized relational database servers on top of Ceph centralized storage have shown somewhat disappointing performance, so I think that could become a real challenge if performance is or becomes a goal. However, I've encountered multiple mentions that Ceph performance is supposed to increase significantly as the number of storage nodes increases (from a handful to a dozen to much larger clusters) and while I cannot corroborate this from personal experience, it stands to reason that "throwing more (hardware) resources at the problem" can make a big difference.