It's metalevel problem, so you should redefine "scheme" concept to "meta-scheme" which should be also distributed. Don't try pre-implemented solutions - ideal would be your own synchronization engine which can be implemented in reasonable time (couple of months) what avoids business issues with predefined solutions. Another issue is interface, should be general and self-constructive enough to enable complex, dynamically changing, distributed schemes and data viewers and editors. Hardware devices diversity is also important point - in case of distributed systems don't be bound to computers but also think of different "storage keypoints" like smartphones or even, for example TV-sets.

Schema evolution in distributed databases can be a real juggling act, but it’s all about careful planning and incremental changes. One strategy I’ve used is a versioned schema approach, where each service or application version has its own schema version. This prevents breaking changes and allows gradual migrations. When adding new fields or tables, I implement a backward-compatible design first, letting both the old and new schemas coexist. Once the migration is complete and stable, we phase out the old schema. Tools like Liquibase or Flyway help manage these changes across distributed environments, keeping everything consistent and in sync without downtime.

There are two basic approaches with regard to the dataset. On one extreme, is to mirror the dataset, on the other is to specialize each instance to the local service/app. The advantage of mirroring is it is well known and there are reliable, fast mirror servers. The query interface is standard across the services. The downside is the data schema is not locally optimized. Specialized instances are locally optimized; however, each service/app has its own queries. The sync engine must be architected to separate send/receive and local queries to put data into the local repo. Though there are third party solutions, their lack of optimization to the localized datasets often cause problems. Building customized sync engines is time consuming.