Show HN: Kedge – Full-stack cloud with forkable VM snapshots and global SQLite

An instant, ephemeral cloud sandbox is pretty handy.

It handles multiple writers by capturing changes as logical operations, then resolving conflicts in a globally-deterministic order based on their contents based on a CRDT model.

There are some limitations (see https://github.com/wjordan/syzy/blob/main/sqlite/docs/LIMITA...), mostly around primary keys (they have to be non-NULL) and UNIQUE constraints (there's some subtle differences in behavior between nullable and NOT NULL uniqueness). But in general, the goal is for all of SQLite, DML and DDL, to just work normally!

The database is eventually consistent by design. For applications that can tolerate eventual consistency across regions, this gives fast local queries everywhere, and services that are resilient to network partitions. A database sitting alone in Virginia gives you slow requests waiting on queries from distant regions, and global downtime if that one load-bearing region goes unavailable for any reason.

The platform does also support persistent volumes (https://kedge.dev/docs/volumes), which is the managed storage API. I've framed it as an escape hatch for those that still need to run a more traditional service with stable members in a fixed region.

I couldn't help it! Ben Johnson recently wrote a Litestream post touching on this topic [1]:

> multiple-writer distributed SQLite databases are the Lament Configuration and we are not explorers over great vistas of pain

I offer my sincerest apologies if this database release may have inadvertently opened the gates of Hell.

[1] https://fly.io/blog/litestream-writable-vfs/

> I didn't immediately spot the durability contract for volumes -- local NVMe like Fly, or sitting on some underlying system like EBS?

Persistent volumes use local NVMe that continuously syncs to object storage, so a similar architecture to Fly Sprites. It automatically recovers from host failures (with on-demand lazy restore), and you can manually migrate stable members to another region if needed.

I've positioned persistent volumes as an escape hatch for when you need an existing database app running in a VM, or when performance requirements outgrow the built-in replicated SQLite.

- Yes, there is a post-restore kernel reseed hook that happens after fork, and just before the trapped listen is continued. It doesn't use the vmgenid driver, it just calls the RNDRESEEDCRNG ioctl, so it would not be compatible with applications that depend on vmgenid notifications to reseed userspace PRNGs.

- In Syzy, the full pruning implementation is deferred for now; at the managed product's current small scale, it can simply eat the tiny overhead costs of un-collected garbage, while the user is only billed for the logical storage space consumed.