Live data from Hacker News

Let's Build PlanetScale from Scratch: Infrastructure

onatm.dev

11–20 of 23 posts

Re: Let's Build PlanetScale from Scratch: Infrastructure

#12
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...

Re: Let's Build PlanetScale from Scratch: Infrastructure

#14
post #12

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…

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?.

Re: Let's Build PlanetScale from Scratch: Infrastructure

#15
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.

Re: Let's Build PlanetScale from Scratch: Infrastructure

#16

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 y…

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 :)

Re: Let's Build PlanetScale from Scratch: Infrastructure

#17
post #16

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 y…

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.

Re: Let's Build PlanetScale from Scratch: Infrastructure

#18

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 y…

The performance definitely sucks but it's not a really serious project. I wouldn't use something like Homescale for using facing products.

Re: Let's Build PlanetScale from Scratch: Infrastructure

#19

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.

Re: Let's Build PlanetScale from Scratch: Infrastructure

#20
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.

Post reply on HN