DATABASES Signal 124
Solid Objects library brings Durable Objects model to any SQL database
↗
Illustration only Photo by Pierre Bamin on Unsplash
Developers can implement per-entity, single-threaded actors with durable state using only their existing SQLite, Postgres, or MySQL instance via the Solid Objects library.
It removes the need for separate locking mechanisms, queues, or Redis instances when building stateful services. By storing state and timers directly in the application’s database, operational overhead is reduced and the model works even inside a browser tab.
Written by elseif from the cluster below · every claim links back to a sourceThe three things worth knowing
Solid Objects provides both a Ruby gem and a TypeScript package that share a common actor runtime design.
The runtime can execute inside a browser tab, using the same database-backed state and durable reminders.
Actor state persists as rows in SQLite, Postgres, or MySQL, so an idle actor costs only those database rows and no extra processes.
THE READ
What the cluster adds up to.
The library introduces the Durable Objects pattern to applications that already run a relational database. It defines an actor as a class with a static type identifier and methods that process messages sequentially per identity. State is loaded and saved as rows in the chosen SQL database, and each message is inserted as a durable row before a worker lease is taken. This guarantees that calls to the same identity cannot interleave, preventing race conditions without external locks.
Adopting Solid Objects requires adding the library as a dependency and configuring a database connection; no new servers, daemons, or monitoring services are needed. Because the database already exists in most stacks, the operational cost is limited to the storage used by actor rows and reminder entries. Idle actors consume no CPU or memory beyond the database rows that represent their state. This contrasts with the managed Cloudflare offering or the self-hosted celld approach, which each add a layer of infrastructure.
The model relies on the database’s transactional guarantees to serialize messages per identity, so performance is bounded by the database’s write throughput and latency. Applications with extremely high request rates per actor may encounter contention that a purpose-built edge network could avoid. Additionally, the browser-tab runtime depends on the storage API available in the host environment, which may limit the size or persistence of the underlying database. These factors mean the solution works best for moderate workloads where existing database capacity is sufficient.
Where the approach stops working is when a system needs sub-millisecond response times or geo-distributed low-latency access that a single database instance cannot provide. If the database cannot handle concurrent leases for many identities without queuing, latency will rise. Moreover, applications requiring multi-region replication without additional setup will not get the automatic global distribution offered by Cloudflare’s edge. In those cases, a durable-objects platform or a custom sharding layer remains necessary.
Written by elseif from the cluster below · checked for specifics the sources never containedTHE CLUSTER