Synchronized persistence is nothing but installing a separate instance of PostgreSQL database on each of the machines where you are installing Qlik Sense, be it central node or rim node.

When you are planning a single node architecture installation, you will have only one instance of repository database on the central node, and the repository will be connected to this central node. In this case, all the data, along with app, will be stored in the local repository. Because there are no other nodes involved in this architecture, you don't need to sync the database.

Following image shows a synchronized persistence installation on single node architecture:

When you are planning a multi node architecture installation, then every installation of rim node, along with the central node, will have their own local copy of the repository database installed on respective servers. Every node will use its local copy of the database to create apps and make changes to them. All these changes are then synced with the central node at regular intervals.

Following image shows synchronized persistence with a multi node architecture:

The advantage of using synchronized persistence is that it allows the database copy to be available on all the nodes. So if a rim node fails, you do not lose any data, because the same has been synced with the central node at set intervals, so you get all the data up to the last sync between the central node and the rim node. When the central node is down, you can still get data from the local database of the rim node, up to the last sync between the central node and the rim node.

The disadvantage of this persistence is that it requires time to sync the data from all the nodes to the rim node. Depending on the network speed between the central node and the rim node, it takes time. This activity will consume server resources for the sync.

Synchronized persistence was available only until Qlik Sense version 3.