La réplication logique démarre en copiant un instantané des données sur la base de publication. Une fois cette étape réalisée, les modifications sur la base de publication sont envoyées à la base de données abonnée au fil de l'eau. La base abonnée applique les modifications sur les données dans l'ordre dans lequel les validations ont été effectuées sur la base éditeur de manière à ce que la cohérence transactionnelle soit respectée pour les publications vis à vis de tous les abonnements.

La réplication se construit de façon similaire à la réplication physique continue (Streaming Replication) (voir Section 26.2.5, « Streaming Replication »). Ceci est implémenté par les processus « walsender » et « apply ». Le processus walsender démarre le décodage logique (décrit dans la section Section 52.3, « Protocole de réplication logique en flux ») des fichiers WAL et charge le plugin de décodage logique standard (pgoutput). Ce plugin transforme les changements lus depuis les fichiers WAL vers le protocole de réplication logique (voir Section 52.3, « Protocole de réplication logique en flux ») et filtre les données en fonction des spécificités des publications. Les données sont envoyées au fil de l'eau au processus apply, qui met en relation les données vers les tables locales et applique les changements individuels au moment où ils sont reçus, dans le bon ordre transactionnel.

Le processus apply sur l'instance de la base abonnée fonctionne toujours avec le paramètre session_replication_role défini à la valeur replica, qui produit les effets habituels sur les triggers et les contraintes.

Le processus apply de la réplication logique déclenche actuellement des triggers de ligne, et non pas des triggers de requêtes. Néanmoins, la synchronisation initiale des tables est implémentée comme une commande COPY ce qui peut déclencher les triggers INSERT en mode lignes et requêtes.