Cross-Database Reconciliation

Your ledger says one thing. Your event lake says another. Find the gap and close it — one query, one tab, no pipeline.

Two databases that share nothing

data.py declares two catalogs. ledger is a live Postgres database holding the orders of record. lake is 5,128,125 payment events in 180 hive-partitioned Parquet files. Different engines, different credentials, different schemas — neither knows the other exists.

The only thing that joins them is the DuckDB in this browser tab, which has ATTACHed both.

The variance query

Every order's true value is the sum of its payment events. So the ledger and the lake should agree, day by day and channel by channel. Where they don't, money has gone unbooked.

This is one SELECT. The left side aggregates Postgres, the right side aggregates Parquet, and the join happens in front of you.

Pick a month. The WHERE narrows the Parquet scan to that month's partitions, which is the difference between a quick query and one that drags all 180 files across the wire.

720 day-channel cells across the half-year. Twelve of them are off-book. Nothing was copied into a warehouse to find that out.

Close it

Reading across two databases is where most federated engines stop. This one writes. data.py exposes public.recon_corrections as "readwrite", so the statement below runs an INSERT into Postgres whose SELECT reads the Parquet lake — from the browser, over the same attach.

It closes the top row of May: 2026-05-21 · affiliate, where the lake holds payment events for orders the ledger never booked at all.

Twenty-one orders, $22,158.55 — exactly that cell's variance. Scroll back up and the May 21 row is gone: a browser tab read a 5M-row Parquet lake, joined it to a transactional database it has no direct connection to, and corrected the ledger.