Very cool! Glad to see all the love for SQLite recently.
One thing I've noticed that many commenters miss about read-replicated SQLite is assuming that the only valid model is having one, giant, centralized database with all the data. Lets be honest with ourselves, the vast majority of applications hold personal or B2B data and don't need centralized transactions, and at scale will use multi-tenant primary keys or manual sharding anyways. For private data, a single SQLite database per user / business will easily satisfy the write load of all but the most gigantic corporations. With this model you have unbounded compute scaling for new users because they very likely don't need online transactions across multiple databases at once.
Some questions:
Will D1 be able to deliver this design of having many thousands of separate databases for a single application? Will this be problematic from a cost perspective?
> since we're building on the redundant storage of Durable Objects, your database can physically move locations as needed
Will D1 be able to easily migrate the "primary" at will? CockroachDB described this as "follow the sun" primary.
I guess the first answer is: similar to Durable Object limits (unlimited databases / 50 GB total) since they alluded to those abilities more so than a simple file stored on R2 (only for backups).
One thing I've noticed that many commenters miss about read-replicated SQLite is assuming that the only valid model is having one, giant, centralized database with all the data. Lets be honest with ourselves, the vast majority of applications hold personal or B2B data and don't need centralized transactions, and at scale will use multi-tenant primary keys or manual sharding anyways. For private data, a single SQLite database per user / business will easily satisfy the write load of all but the most gigantic corporations. With this model you have unbounded compute scaling for new users because they very likely don't need online transactions across multiple databases at once.
Some questions:
Will D1 be able to deliver this design of having many thousands of separate databases for a single application? Will this be problematic from a cost perspective?
> since we're building on the redundant storage of Durable Objects, your database can physically move locations as needed
Will D1 be able to easily migrate the "primary" at will? CockroachDB described this as "follow the sun" primary.