- The lazy migration design is clever for the common case, but I keep getting stuck on what happens when a migration isn't just "add a column." If you need to backfill a derived field or rebuild an index across a restructured table, some unlucky user's request becomes the one that absorbs thirty seconds of migration work instead of the usual milliseconds. And you can't really pre-migrate millions of idle databases either, since the whole point is they only wake on demand. Is there a pattern people are using here, like versioned read paths that serve old-schema data while migrating in the background, or is the practical answer just "don't write heavy migrations"?
- We recently replaced an isolated feature built on Durable Objects with Rivet Actors, to allow for much better interop with the rest of our infra (which is built on AWS/Vercel), and are happy with it so far.
There have been some small issues but nothing show-stopping, and the Rivet team has been very responsive to help get things sorted (or help us understand when it was us doing something wrong).
Not using the SQLite datastore yet, but I am excited about the possibilities!
by siliconc0w
1 subcomments
- Really interesting to see these new compute paradigms. I haven't built anything on Durable Objects yet but I can see the appeal and I'd prefer an OSS option.
SqliteDB per tenant may make sense, not sure about per actor. You really don't want to re-implement database transactions.
by swaminarayan
1 subcomments
- “sqlite per actor” feels like very clean actor level isolation. the part I am more curious about is how you recommend handling cross actor queries.
by ZeroAurora
1 subcomments
- I love the idea of DOs and I'm happy to see an OSS implementation.
Would it be interesting to write about comparisons against Cloudflare Durable Object to the project README? Both for clarity and marketing reasons.
- It’s crazy how pretty much every tool people post to support AI systems is already in Erlang/OTP or in elixir standard libraries.
- I get where you come from, but really needs it to be a whole SQLite instance per database? Wouldn’t be more efficient just logic separation in a larger DB?
Better usage of resources and it always allows a parent style agent do complex queries (e.g: intersection of two different actors data doesn’t need to fetch all, copy and do it in buggy non sql code)
by OussamaAfnakkar
0 subcomment
- [dead]
by nimbus-hn-test
0 subcomment
- [dead]
Hacker News