This is an extremely good question. Few things that come in mind:
If the databases are autonomous and do not need almost any information from each other, then separate database servers would probably be the easiest solution. The client application would only be configured so that it connects the correct server and instance
If the databases need to share small amount of information I would use a single master database containing the common data which is either accessed via linked servers or replicated if the reliability of the connection is not tolerable. Rest of the tables would be located on country specific databases.
Things get interesting if you need to access all the databases inside the same queries. If this is a requirement I would recommend investigating
Understanding Federated Database Servers[
^]. Using federated view would most likely require some logical changes in the application but if the database is going to be spread along multiple servers based on clients then small changes probably cannot be avoided.
Of course Azure would be one topic to discuss but you wrote
"
But the customers doesn't want their customer data leave out of their country." so cloud based storage is probably out of question.
ADDITION:
---------
When the two servers are far away from each other, few things to take into consideration:
- Overall speed, how fast the connection between the servers really is
- Variance in speed, does the throughput vary a lot
- Reliability, has the connection connectivity problems
- Need for the link, do majority of the queries execute based on local data even though it's possible to fetch remote data. This applies mainly to the federated views.
All these factors affect the situation. For example if most of the queries need data from both local and remote servers, then it is probably best to 'cache' the remote data locally for example using replication.
On the other hand if the application needs to access most recent data then copying the data may not be the right choice and you need to fetch it when needed. This means links or other mechanism but also may introduce performance bottlenecks and reliability problems.
So in the end, there's no correct answer and what may be the best solution today may be second best tomorrow because connectivity and throughput evolves all the time. In order to decide what is best for your situation you need to go through all the requirements you have and compare different options against the required functionality. After all the decision is going to be a compromise, one way or another.
Submit an article or tip