Brute force approach: Send it the ".dump" command to create a text representation of the data. Read that data in into the second database. Not sure you can use that.

If you need a fine grained update (sending a copy of each upto the other copy), have a look at sqlite3_update_hook

But how do you plan to handle errors? For example, what happens when the copy of the DB in app2 can t make an update for some reason?

To solve this, move the database to a server process and have the two apps talk to it.

Out of the box, no. There are a small number of third-party options:

SQLite sync: https://ampliapps.com/sqlite-sync/ This one seems attractive because it can replicate to other databases as well as SQLite, and doesn t modify the SQLite engine. I haven t tried it yet.

Litereplica: http://litereplica.io/ One way only. Seems to have been around a bit.

LiteSync: http://litesync.io/ Two-way replication. Pretty new, but an evolution of Litereplica so probably more mature than it appears. I have tried this a bit and it does seem to work smoothly, with a few bugs which the developer is looking at. You have to use the developer s modified SQLite engine, which seems like a concerning dependency. You also don t get much control, e.g. you can t say replicate now without reopening the database.

Lsyncd - Live Syncing (Mirror) Daemon may be of use here. It uses rsync to do continuous replication on the file level.

If you want replication in an in-memory database you need to look at berkeley DB (BDB). However the data model for BDB is string-string dictionary, so you loose the flexibility of SQL. plus it has a three clause license, so if your project is commercial you need to get licenses.

We still do not have native support, although we have some improvements in backup, check docs, but we have more third party options: welcome Litestream, which is published and developed in a similar way to SQLite.

No it doesn t because the project s scope is being a simple in-process database. But because the database is just a single file, you could write your own replication script based on plain file copy operations, rsync or something similar.

If you really want a SQLite based client/server type of RDBMS, you could take a look at SQLiteDBMS.

Unison? Best you could do though was hot spare, because SQLite db in one monolithic file. You couldn t round-robin between the two "instances". Hot spare isn t bad, you simply pick up the other app+db without much fuss, compare to MySQL master-slave or active-passive where there is some manual intervention which is not easy. MySQL replication passes around SQL, not just diffs like unison/rsync. But with unison you have master-master.