Clockwork Labs schedules two SpacetimeDB scaling features for October 31

Why it matters

SpacetimeDB makes developers choose workload boundaries instead of hiding distributed coordination. The two planned October 31 capabilities will test whether tiered storage and explicit inter-database communication provide a practical path beyond one machine's memory without giving up serialized execution.

Clockwork Labs plans to ship two SpacetimeDB scaling capabilities on October 31, 2026: asynchronous inter-database communication and tiered storage. The company calls the effort Spacetime Continuum, but its published roadmap assigns the date specifically to those two features, rather than every item in its longer-term scaling plan.

CEO Tyler Cloutier is preserving a defining constraint of SpacetimeDB, Clockwork Labs' relational database and synchronization system: one database executes transactions on one thread, even when an application grows beyond one machine. The October features are intended to increase storage capacity and let independently executing databases communicate without replacing that ordered execution model.

Cloutier's design requires developers to divide suitable workloads across databases, each operating as an independent actor. Clockwork Labs intends to make those boundaries easier to manage rather than route every transaction through a general-purpose distributed coordination layer. In the company's account, the architecture favors fast local transactions and incurs coordination latency when data crosses a database boundary.

That tradeoff has been embedded in SpacetimeDB since Cloutier and CTO Alessandro Asoni built the technology for BitCraft Online, Clockwork Labs' persistent multiplayer game. The founders originally started a research-data and lab-notebook product called SkyLab before pivoting toward the open-ended MMORPG they wanted to play, Cloutier said in a 2021 interview. Cloutier had worked on large-scale mobile games at Machine Zone, while Asoni had built bond-pricing infrastructure at Bloomberg.

BitCraft forced the pair to confront a backend problem that many database companies encounter later: a shared world produces frequent transactions against overlapping state, exactly where distributing work across machines becomes expensive. SpacetimeDB emerged from that constraint. Clockwork Labs later packaged the database, embedded application logic and real-time client synchronization as one system for outside developers.

Founded in San Francisco in 2019, Clockwork Labs described itself as fully remote in its 2022 financing announcement. The company has not disclosed current customer identities, workload volumes or revenue.

A scaling plan with one delivery date and several undated items

Each SpacetimeDB database currently runs as a single-threaded actor, according to Clockwork Labs. The company says SpacetimeDB Cloud can replicate that actor across machines through distributed state-machine replication, providing redundancy when a node fails. Replication does not increase the rate at which one database can execute contending write transactions because those transactions still pass through one ordered execution stream.

Storage has a harder physical limit today. Cloutier wrote that all table data for a database remains in memory on its leader node, constraining the working set to the machine's available RAM.

As of September 4, 2026, the two October 31 capabilities remain planned rather than shipped:

• Asynchronous inter-database communication, which Clockwork Labs says will allow one database to call functions on another in a type-safe way.
• Tiered storage, which is intended to extend tables from memory onto disk and object storage.

Clockwork Labs' official roadmap gives October 31, 2026, as the planned date for both features under the Spacetime Continuum name. In that post, the company presents its scaling work in this order: replicated databases, asynchronous inter-database communication, tiered storage, consistent read replicas, synchronous inter-database transactions and intra-database partitioning.

Replication is available today. Read replicas, intended to distribute subscription and query traffic, remain planned without a delivery date. Clockwork Labs also lists synchronous transactions spanning databases and partitions that would let one logical database contain multiple independently executing shards, without specifying delivery dates for either capability.

The sequence reflects Clockwork Labs' architectural argument. Asynchronous communication and explicit databases can handle workloads that already have natural boundaries, such as game regions, tenants or isolated application components. Cross-database transactions and automatic partitioning are planned for applications whose boundaries are harder to draw, though both would add coordination machinery that SpacetimeDB's current design avoids.

Cloutier said in the scaling post that BitCraft uses one root database for global data and regional databases for separate areas of its world and groups of players. Clockwork Labs also says several customers operate hundreds or thousands of databases through the existing child-database model. Those company-reported figures describe independently executing database actors or shards. They do not establish end-user counts, the number of databases hosted on one machine or production traffic.

Cloutier is defending the lock

In Cloutier's account of SpacetimeDB's architectural history, the prototype used Postgres and Kafka before Clockwork Labs developed its own storage and execution engine. He wrote that early custom-engine versions used parallel execution with multiversion concurrency control. Measurements subsequently led the team to adopt serialized execution by design.

Cloutier estimates that the work leading to serialized execution under what he calls a "big ol' lock" may have cost Clockwork Labs more than $1 million. He argues that parallel and distributed databases incur costs from locks, retries, cache synchronization and network round trips when transactions contend for the same data.

Clockwork Labs' public benchmark remains a company-reported performance claim. Its May 2026 post acknowledged that earlier figures had been misleading because of implementation problems. In the revised May 14 benchmarking post, Clockwork Labs reported 303,920 +/- 4,712 transactions per second for SpacetimeDB Standalone at alpha=1.5. The TypeScript transfer test used power-law account selection, creating contention among frequently selected accounts, and the result followed an improvement to SpacetimeDB's V8 threading model.

The company describes the benchmark as a full end-to-end transfer-throughput test using a single-node Standalone deployment. The result should remain explicitly limited to the stated single-node workload and should not be presented as an independently verified database-wide rate. Clockwork Labs says its methodology used a five-minute measurement window after a 30-second warmup, reported error bars as one standard deviation and included code and a command for reproducing the test.

The scaling post makes a narrower case. Clockwork Labs says horizontal scale depends on whether a workload can be divided. SpacetimeDB is intended to expose those divisions through databases and partitions, preserving single-threaded execution inside each unit while running unrelated units concurrently.

Tiered storage will test another part of the design. Cloutier writes that a transaction encountering nonresident data will abort before committing while the system fetches the data asynchronously. Other transactions can continue, and the original transaction runs again once the data arrives. Clockwork Labs attributes that behavior to its deterministic, isolated reducers, whose failed work is rolled back and which cannot perform arbitrary I/O during execution.

October 31 is Clockwork Labs' stated delivery date for the two capabilities, and neither has shipped. Their usefulness will depend on the latency of cold reads, the working sets that remain practical, migration behavior and the economics of storing large tables outside memory.

The database market is funding the abstraction fight

Clockwork Labs has disclosed $26.3 million in funding. A $4.3 million round announced in 2021 included Supercell, Firstminute Capital, 1Up Ventures, Supernode and Skycatcher. Andreessen Horowitz led a $22 million Series A in 2022, with Roblox founder David Baszucki participating. Clockwork Labs said that round would fund both BitCraft and the database technology behind it.

Convex, a TypeScript-oriented reactive backend, raised a $57 million Series B on August 4, 2026. Convex and SpacetimeDB both combine transactions, live data synchronization, typed APIs and backend logic, although their language support, deployment options and data architectures differ. Funding in the category does not validate SpacetimeDB's execution model or establish that the products perform similarly under contention.

SpacetimeDB's public repository had approximately 25,000 GitHub stars as of September 4, 2026. That indicates developer attention, not production scale. The available workload evidence still comes largely from Clockwork Labs: BitCraft, unnamed customers running many separate databases and the company's own benchmarks.

The October delivery will test a precise proposition. Cloutier and Asoni built SpacetimeDB around serialized execution because it simplified transactions for a shared game world. Tiered storage and explicit inter-database calls must now make that model practical for applications whose data exceeds one machine's memory, while leaving developers responsible for deciding where one ordered world ends and another begins.