What I'd like to enable here is a progression where you start out prototyping your app with a single D1 database, which is easy to use and reasonably fast. Then as you grow we provide tools to let you transition to many D1 databases sharded in a way that makes sense (e.g. per-user). Apps that want even more control can move to using full-on Durable Objects (which will soon support a SQLite database per-object).
That said, there are certainly many use cases out there where simple monoliths make sense, especially non-interactive data crunching. I'm not sure yet if D1 will ever be the right choice for those, but the Workers platform aims to provide many options.
I've only started to think about this and I'm thinking the hardest part will be dealing with cross-cutting concerns (in a non-auto sharded world manually creating multiple database) and trying to find a way to keep each database isolated without extra burden compared to using a hosted Postgres.
As an aside, that lan optimized house was a gaming dream. Hope your new house is as awesome.
Can you elaborate this little bit more? Im using DO today and i have a bad time sharding my data (works, but i hate it);
So i will have the option to use the standard store or/and SQLite?
If so, i dont can keep with my DO (because i have control of everything) and use SQLite for things that is bigger than what the value store supports.
In the future each DO will have a private SQLite database. The key/value store will actually be redirected to store into a special table in this database, but probably new apps will just use the database and not the KV store.
Separately from that, I would like to develop tools that make sharding Durable Objects (and D1 databases) easier. Today it's a pain to do manually. This is independent from the underlying storage model, though.
For comparison, fly.io, turso's provider, has 34 locations and well-documented reliability issues.