800 TB, 6,000 Tenants, Complex Business Logic: A SaaS Platform Moves From Oracle To PostgreSQL

A multi-tenant SaaS platform of a FinTech company ran on Oracle. 800 TB of it, holding the production data of more than 6,000 customer organisations. Some of those customers were rows in shared tables. Others had schemas of their own, provisioned dynamically as the customer was onboarded. A large amount of the application’s business logic lived in the database as PL/SQL, and parts of it behaved differently depending on which tenant was calling it. The destination was Amazon Aurora PostgreSQL. The constraint was that no customer could lose access to their own data during their own busy period, and there was no window in the calendar where all 6,000 were quiet at once.

The database was not the hard part. The tenants were. We could not produce a complete list of what we were migrating on the day we started, because the source did not hold one. The tenancy model was mixed, the per-tenant schemas were a runtime property rather than a declared one, and on top of that six thousand customers had accumulated years of drift - feature flags that changed which columns exist, per-customer extensions, code lists that mean different things to different tenants, and historical data that only one customer’s configuration explains. The business logic had drifted the same way the schemas had, so the PL/SQL was not one body of code with 6,000 callers but something closer to a family of variants. A migration that treats them uniformly is a migration that quietly corrupts a subset of them, and you find out which subset when that customer closes their quarter.

This session walks the whole engagement. How we discovered what was actually there before we could plan anything. How we sequenced 6,000 tenants rather than 20 databases, and why the unit of work is the tenant and not the table. What we did with the business logic, which is where the real conversion effort went and where the tenant-specific behaviour was hardest to see. What per-tenant validation had to prove before anyone would sign a cutover, and how we proved it against a source that was still live. Where Aurora PostgreSQL behaved differently from what an Oracle team expects, in ways that only surfaced under production concurrency. Where Percona’s performance work on the Aurora side changed the design rather than tuning around it. And the estimate we got wrong, which is the same estimate everyone gets wrong on multi-tenant migrations.