Ah, ok, I'm failing to communicate my point. The underlying problem in this scenario is something basic which doesn't require replication/sync at all. I'll use an actual example that fell on me a while back. There was an app that displayed a news feed. The theoretical upper limit of the volume, due to the size of audience, was hundreds of posts per day, while the practical number was dozens. The architecture was:

* postgresql as the system of record

* firestore as the upstream source for clients

* ES for full-text search

* client-side store for actual client-side reads

* http api for mutations

That required three sync systems: pg->firestore, pg->ES, and firestore->local store. Then it needed messages for the async mutations to propagate back to the clients. And then these things require more things to make them work, like data transformers to support the three different formats for each stage.

This certainly did not require some giant CQRS system and could have been built entirely on postgres. It was a fractal of code that didn't go toward the actual objective.