One large central database and many small ones with partial replication, what are the options?

Question

Database

Hello.
This problem can be solved programmatically. But I wonder if there are ready-made options at the level of the DBMS or modules for any DBMS (no matter SQL or NoSQL). A question from the field of "search for alternatives, suddenly there is better."
The bottom line is that the central database stores a lot of data. The data is of the same type, but the data of one application is in several separate tables/collections related only to this application. Many containers or remote clients are running, where there is a small database that stores only the data of this client. It is necessary to synchronize changes in the data, both those made on the client side and on the side of the central database.
If anyone has encountered a similar problem, it will be interesting to at least give a hint of how it was solved. Or saw the description in some DBMS.

Answer 1

In one of our projects, we did this:
the backend was a REST API that gave each client only the data that concerned its identifier. For data version control, a table with client_id, version, action was used, and each client downloaded the accumulated difference.
Clients periodically, every 5-10 minutes, performed polling from the server with the accumulated changes from the client, while the server centrally stored and managed all the changes.
If the connection failed, the connection was retried according to the period. So offline clients worked even with outdated data, but they still worked.