Article URL: https://onatm.dev/2026/07/16/homescale-part-1/ Comments URL: https://news.ycombinator.com/item?id=48933303 Points: 82 # Comments: 16

I worked for a database tools company many years ago and was lucky enough to build a few database cloning tools before PlanetScale was cool. Those tools were never destined to be as successful as PlanetScale, but they had their uses. The idea behind those tools was simple: isolate the storage layer from compute and use the best storage technology for cloning the database files. This idea came back to me a while ago while I was tweeting about an interview I had with an F1 team that was looking for a Rust dev with hands-on Ceph experience. Mentioning Ceph reminded me of a failed product attempt I was part of, and I jokingly told a friend that I was going to build Homescale, PlanetScale at home. Homescale creates writable database instances and point-in-time branches from immutable snapshots without copying the full database. I borrowed Docker’s image and container model to represent the database state: A database image is an immutable starting point. A database container is a writable clone created from that image. A branch is another container created from the current state of an existing container. The examples in this series use Postgres, but Homescale’s storage model is database agnostic. The image, container, and branch model can apply to any database engine that keeps its durable state on a filesystem backed by a block device and can be prepared for a recoverable snapshot. Postgres is the first engine I plan to support and gives me something concrete to use while building the storage and orchestration layers. Engine-specific behavior belongs behind an adapter. That adapter initializes an image, starts the database process, exposes connection details, and prepares the database for a snapshot when necessary. Homescale handles the lifecycle around it: volumes, immutable states, writable clones, workloads, and lineage.