There is no in-place replacement. Most likely your app relies on database performance for a lot of queries, that can be fast only on local databases. This make

There is no in-place replacement. Most likely your app relies on database performance for a lot of queries, that can be fast only on local databases. This makes a serious rewrite necessary if you want to go with distributed solutions and requires knowledge and experience in distributed systems. Which takes a lot of time and that's why choosing distributed databases from the beginning instead of MySQL/PosgreSQL is so important. Judging by your description, your best bet is probably pre-sharding. It's not a proper distributed solution, but it doesn't sound like you need one. It works like this: you partition your data into N shards, where N is two orders of magnitude higher, than the number of server you plan to have, then split each table into N tables belonging to each shard and use a static mapping of shards to servers in the application. Queries won't be able to cross shards. Some work on the app will be necessary and on the infrastructure tooling to manage servers, shards, replication, monitoring. As you would need to be able to move shards between servers, restart them, backup them and so on.