Rivet 3.0 is built on S3 But we did something completely different... And oohhhh boy: - 6.9 ms actor cold starts (durable) - 0.69 ms SQLite writes (3 availability zone) - 0.20 ms SQLite reads Here's how we built our new storage engine, WarpDrive. ~~~ Most S3-backed database read & write straight to S3. That means: - Every commit & cache miss is an S3 request ($$$) - S3 downtime takes you down (SLA allows 8 hours downtime/yr!) - S3 Express is limited to one availability zone This usually ends up slow, expensive, and has poor tail latencies. For Rivet 3.0, we decided we could do better. We wanted 3.0 to ship with: - SSD speeds with storage on S3 - Stateless nodes - No dependencies ~~~ To do that, we built WarpDrive to durably write your data on fast disks *before* we write it to S3. Every write on WarpDrive is: 1. Written to disk in 3 availability zones 2. Acked once a majority has them 3. Then batched to S3 in the background That means that Rivet has: - Writes that get durably acknowledged insanely fast - Fewer S3 operations by batching in the background - Survives S3 outages for new & warmed actors - Nodes remain stateless - S3 is the only dependency ~~~ WarpDrive is something we're incredibly proud of and can't wait to have you try for yourself. Rivet 3.0 with WarpDrive is in preview today. It's available on Rivet Cloud or for self-hosting today. Please send feedback on X, Discord, or DMs -- we want to hear anything and everything you have to say (please bump me if I missed a message!) There should be no reason to vendor lock yourself to Cloudflare Durable Objects if you can have better performance, better DX/AX, lower cost, and more flexibility on software you own. And of course, it's all open source.