- Sources: primary, repository, discussion, discussion
- Summary: Each celld node embeds V8 and executes Wrangler bundles, each object is its own SQLite database continuously replicated to an S3-compatible or Google Cloud Storage bucket as LTX segments, and object-storage compare-and-swap decides which node owns a cell, so the design carries no membership protocol, no failure detector, and no consensus service. The repository is
denoland/celld under Apache-2.0 with 3,300 stars and a ry@deno.com contribution address, pull requests are disabled, and the project asks for git format-patch by email under a contributor agreement assigning rights to Deno Land Inc. The figures on the project page are the project's own and were not reproduced here, including roughly 90 ms region-local durable write latency, RPO of 0, about 20 seconds to fail over after node loss, 0.47 MB of RAM per resident cell, and about 2,500 resident cells per 8 GB node, and the page states its own measurement conditions, that speed and density come from one node running trivial cells on an Apple M-series laptop over loopback while fleet activation p50 is 35.9 ms on a 2 vCPU node. - Why it matters: The Durable Objects programming model has been reachable only by deploying to one vendor, and running the same code against storage and machines the operator picks changes the tenancy and the failure domain rather than only the bill.
send feedback on this story