It’s crazy how pretty much every tool people post to support AI systems is already in Erlang/OTP or in elixir standard libraries.
Show HN: SQLite for Rivet Actors – one database per agent, tenant, or document
11–20 of 21 posts
Re: Show HN: SQLite for Rivet Actors – one database per agent, tenant, or document
#12I 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.
Thanks! Any questions in particular on the comparison?
Re: Show HN: SQLite for Rivet Actors – one database per agent, tenant, or document
#13It’s crazy how pretty much every tool people post to support AI systems is already in Erlang/OTP or in elixir standard libraries.
Yep, everyone seems to reinventing the actor model from first principles right now.
We're taking a different approach of building the best actor primitive for mainstream languages and letting people build a thin AI layer on top. We did not set out out build for AI when we started it, it was a happy accident.
Re: Show HN: SQLite for Rivet Actors – one database per agent, tenant, or document
#14Really 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.
Cheers!
Re: Show HN: SQLite for Rivet Actors – one database per agent, tenant, or document
#15It’s crazy how pretty much every tool people post to support AI systems is already in Erlang/OTP or in elixir standard libraries.
Yep, everyone seems to reinventing the actor model from first principles right now. We're taking a different approach of building the best actor primitive for mainstream languages and letting people build a thin AI layer on top. We did not set out out build for AI when we started it, it was a happy accident.
How do you intend to conquer the preemptive scheduler? System-wide fairness and preventing starvation are essencial steps for this to work well.
Re: Show HN: SQLite for Rivet Actors – one database per agent, tenant, or document
#16[dead]
Re: Show HN: SQLite for Rivet Actors – one database per agent, tenant, or document
#17The 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"?
Re: Show HN: SQLite for Rivet Actors – one database per agent, tenant, or document
#18I 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.
Thanks! Any questions in particular on the comparison?
Theory, performance, self-host option, estimated cost, etc. And I see you can deploy rivet on Cloudflare DOs. What situation does it help when we can just use wrangler?
By the way, Cloudflare DO is actually self-hostable with workerd to my knowledge, but it's not an out-of-box experience.
Re: Show HN: SQLite for Rivet Actors – one database per agent, tenant, or document
#19The 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 eith…
You can pre-migrate if you want, just by hitting every actor with a request as soon as you deploy the change with a migration.
Personally I think the benefits of lazy outweigh the downside of that single 30s request, but to each their own.
Re: Show HN: SQLite for Rivet Actors – one database per agent, tenant, or document
#20[dead]