Reading through the README, this piqued my curiosity:

> Small or fast transactions may share the same WAL position.

I don't think that's true; each data change and each commit (whether explicit or not) has its own dedicated LSN.

> LSNs should be treated as monotonic but not dense.

That's not correct; commit LSNs are monotonically increasing, and within a transaction, event LSNs are monotonically increasing. I.e. the tuple commit-LSN/event-LSN is monotonically increasing, but not LSNs per se. You can run multiple concurrent transactions to observe this.

This is just the transport - raw XLogData frames and LSNs. Use pg_replicate, as an example, if you need "replicate to BigQuery." Use this if you're building replication infrastructure.

What it does:

- Explicit LSN control - start/stop at specific WAL positions for deterministic recovery

- Automatic standby feedback - no more forgotten heartbeats filling your disk with WAL

- Bounded channels - backpressure propagates to Postgres naturally

- Pure Rust, no libpq

What it doesn't do: pgoutput decoding (intentionally). That belongs in a higher layer. Simplest way of using this:

while let Some(event) = client.recv().await? { match event { ReplicationEvent::XLogData { wal_end, data, .. } => { process(&data); client.update_applied_lsn(wal_end); } _ => {} } }