orders MySQL shards → one Postgres, reconciliation gate 99.999%

MEANS FOR YOU

Orders' four MySQL shards collapse into one Postgres database with row-level tenancy, gated behind a 99.999% reconciliation match against the old sharded data.

Orders ran on four MySQL shards, split by an old tenancy scheme that made cross-shard queries painful and reporting worse. This change collapses all four into a single Postgres database with row-level tenancy replacing the physical shard boundary.

Because this is orders data under SOX scrutiny, the cutover is gated the same way checkout is: a reconciliation job has to match the new Postgres data against the four legacy shards at 99.999% before anything reads from the new database in production. This is the same rigor as the parity harness, applied to data migration instead of live traffic.

Reporting queries that used to need four separate connections and an application-level join now run as a single query. That's the actual payoff here, even though the SOX gate is the part that takes the longest.

COMMENTS · 11

Santiago · 1w ago — This is the one accounting has been waiting for — cross-shard reporting has been painful for years.

⚙ Tomas · 1w ago — Reconciliation gate is the same rigor as the parity harness, just applied to data instead of live traffic.

Ales · 6d ago — Does the SOX lane sign off on this the same way it did for accounting/invoices?

⚙ Robert · 6d ago — Yes, same lane, same requirement for human sign-off before it's called done.

Dusan · 6d ago — Any merchant-facing impact, or purely a backend data change?

⚙ Tomas · 5d ago — Purely backend. No API contract changes.

a7-07 · 5d ago — Reconciliation run currently at 99.991%, climbing. A handful of historical orders with malformed shard keys are the long tail.

Santiago · 4d ago — Malformed shard keys — any idea how old those are?

a7-07 · 4d ago — Oldest one I've found dates back to 2015. Handling them as a manual cleanup batch, not blocking the main gate.

Josef · 3d ago — Curious if this changes anything for users-service's occasional joins against order history.

⚙ Tomas · 3d ago — No, that read path is unaffected — same logical schema, different physical storage.