J'arrive après la bataille, j'ai un peu lu la doc technique de litestream.
Donc. Ça court-circuite le WAL/checkpointing pour avoir le temps de faire des copies du WAL sur une autre machine. C'est comme ça que postgres fait des replicas, rien de choquant /à priori/.
Mais: le réplication c'est une solution compliquée à 2 problèmes. 1/ de la haute disponibilité (si ça plante, on peut basculer sur une autre machine). SQLite est pas bon à ça, ça ne permet pas de faire des migrations à chaud (réponse à ça dans l'article: "oui c'est à froid mais ça va vite sur un SSD") - je pourrais détailler mais ici la réplication permet pas de faire la migration pendant que la réplique sert du trafic (alors que ça pourrait - au moins en lecture).
2/ supporter plus de lectures concurrences. C'est un problème car SQLite n'utilise pas des locks très fins et une base de données SQLite n'est pas conçue pour être lue par plusieurs processes. Donc il cherche à micro optimiser des lectures, mais sacrifie le p99 (=la majorité des requêtes sont très rapides, mais certaines seront très lentes).
Je pense que configurer Postgres (avec pgtune pour même pas avoir à réflechir) sur une seule machine avec du RAID et des backups réguliers, ça suffit.
Il mentione d'autres trucs plus complexes (eg: pgbouncer) en disant que c'est relou à configurer. Vrai, mais 1/ c'est généralement pas nécessaire, 2/ et litestream/sqlite répond pas à ces besoins.