> Now we face new challenges: figuring out which data should be moved to the edge, finding efficient ways to transfer data from centralized data centers to the edge, and keeping everything in sync.

Why would you need to do this? D1 is meant to be a complete database and intention is to host everything there.

> However, when you involve a database, this advantage starts to fade away.

Why? Define database and what your needs are. Dynamodb or Cosmosdb for example can be multi-region read/write databases. You can deploy it in every region supported if you need to. What is missing?

Other examples...

- Mongo Atlas (hosted mongodb) supports global multi-region.

- Astradb (hosted cassandra) supports global multi-region.

- Cockroachdb supports global multi-region. It has a more interesting approach of allowing you to specify the "home" region per row.

D1 is currently limited to 100 MB, and I'm doubtful it's meant to be a complete database. As I understand it, it's more for "manual cache" purposes and not for hosting everything there (think about 100 TB of data).

Regarding your second comment, while it's true that all the solutions you mentioned allow you to deploy a DB, they are offering between 5-10 locations around the world, compared to 100+ locations of Edge solutions.

Anyway, that's not the main point. I still don't think it's the right way to create read replicas for all your data in all locations. There should be a better way to copy only the relevant data (the data you want to fetch with low latency).

Until we go interplanetary[0] —or unless you have a very time-sensitive database application— it's already[1] all edge.

[0] lunar would also work

[1] I consistently get <300ms pings to servers 12 time zones away. But I grew up in an era when long-distance (tens of km) phone calls were exorbitantly expensive, causing us to wait to transfer data for night rates, so YMMV.