3 min read

Building Homescale with Ceph and Kubernetes

A new Homescale project aims to clone writable database instances from snapshots without full copies, using Ceph RBD and Kubernetes storage APIs.

Image: Hacker News

Homescale is an attempt to bring PlanetScale-style database branching to a homegrown stack. The project, published at github.com/homescale-dev/homescale, creates writable database instances and point-in-time branches from immutable snapshots without copying an entire database first.

The core model borrows from Docker. In Homescale, an image is an immutable starting point, a container is a writable clone of that image, and a branch is another writable container created from the current state of an existing one. The planned CLI looks like this:

  • homescale image create --engine postgres postgres-base
  • homescale container create --image postgres-base dev-db
  • homescale container connect dev-db
  • homescale branch create --container dev-db feature-login
  • homescale container connect feature-login

The first target is Postgres, though the author says the storage design is database agnostic as long as the engine stores durable state on a filesystem backed by a block device and can be prepared for a recoverable snapshot.

Recommended reading

FBI eyes Nvidia and Google TPU AI systems

At the heart of the design is copy-on-write (COW) storage. Instead of duplicating a 100 GB database to create a branch, the child instance initially shares unchanged data with its parent snapshot. Storage usage grows only as the two diverge. That makes branching cheap up front, with initial cost mostly limited to metadata.

Why Ceph RBD fits the design

For the storage layer, the project uses Ceph, specifically RADOS Block Device (RBD). An RBD image behaves like a normal block device that can be mounted and formatted, while Ceph handles snapshots and writable clones underneath.

The branch flow maps neatly to Ceph operations:

  • create an RBD snapshot
  • protect that snapshot
  • create a writable clone from it

The author shows the equivalent rbd sequence:

  • rbd snap create homescale/dev-db@feature-login
  • rbd snap protect homescale/dev-db@feature-login
  • rbd clone homescale/dev-db@feature-login homescale/feature-login

Ceph stores RBD data as objects in RADOS, with objects mapped to placement groups and then to OSDs. The default object size is 4 MB, which means a small database write can still trigger a larger underlying allocation when shared data is copied into a clone.

Kubernetes handles orchestration

Rather than managing database processes and storage directly, Homescale uses Kubernetes as its control plane. The CLI talks to the Homescale API, which creates PVCs, VolumeSnapshot resources, and database workloads. Ceph CSI translates storage requests into RBD operations, while Rook manages the Ceph cluster itself.

The first deployment target is a local macOS setup running a single-node Kubernetes cluster, likely via Colima or Lima, with one Ceph OSD and one storage device. The author may also deploy it to a private Talos cluster on Hetzner Cloud, where a replicated Ceph pool with size: 3 and failureDomain: host could keep volumes available through node or disk failures.

That split is the point of the project: Homescale asks Kubernetes for PVCs and VolumeSnapshot resources, and the underlying Ceph stack handles snapshots, clones, and persistence.

Marcus Vance

Enterprise Editor

Marcus follows the money. He covers enterprise software, cloud architecture, and the tectonic shifts in Big Tech strategy. He translates dense earnings calls and complex M&A activity into actionable insights about where the industry is actually heading. If a tech giant makes a silent pivot, Marcus is usually the first to notice.

via Hacker News

// Keep reading