Synchronous replication?

[Sleepful]

I know synchronous backups for all writes could potentially block the database too much.

However, it would be ideal if I could configure synchronous replication for a specific table.

There's always that "ledger" table in most systems that cannot afford to lose the last 5 seconds of writes if the system goes down.

Right now the only "workaround" is using a separate HTTP API database for these tables, which fragments the tech stack further.

Let me know if there's something I'm missing to fix this kind of durability problem. However, CMIAW, tools like pgBarman for Postgres support synchronous backup.

[benbjohnson]

It's difficult to make synchronous replication work within Litestream since it runs as a separate process so there's not a consistent way to block new transactions before the next one starts. The best we could probably do is give you an API for reading the current TXID & the furthest replicated TXID. Then in your application code you could write something like:

1. Read current TXID
2. Execute write against ledger table
3. Poll replicated TXID until it matches at least the previously read TXID + 1