Database in a SaaS application
summary
Postgres then Oracle were used for a SaaS training platform, but scaling issues came from a flawed design: a naive per-client schema for translations caused massive duplicated rows (millions → tens of millions) and disk-bound joins; search was implemented as a DB-driven XML queue with database-generated XML and brokered indexers that overloaded storage; reporting ran per-row aggregations over a view on ~120M report rows, producing extremely expensive queries. The fix described is to monitor performance, split responsibilities by moving translations, search, and reporting into separate services, and use an ETL-fed reporting database for analytics.
AI-written summary · about
chapters (6)
- 0:00SaaS and databases intro
- 5:38SaaS database design
- 13:46App translations
- 20:07Search in SaaS
- 31:36Data reporting
- 40:53Summary
related talks
46mBig databases, many servers, data center or cloud - it's all here!
25mData-intensive PostgreSQL: Three ways to scale
17mBuilding a Scalable and Performant SaaS Platform with YugabyteDB
40mDB for next project? Why, Postgres, of course
29mTales from the Field - Oracle to PostgreSQL migrations
37mDatabase Modernization at Cloud Scale: Minimizing Risk and Disruption
57mPatterns of SaaS: Refactoring Databases
46mWhy PostgreSQL is becoming the standard in Financial Services