Case Study, Converting the CATME application from MySQL to Postgres
summary
Converting CATME from MySQL to Postgres uses concrete, repeatable steps: run automated sed awk Perl scripts to rewrite about 80–90% of SQL, handle manual refactors for date math and CASE logic, replace MySQL’s ON UPDATE CURRENT_TIMESTAMP with application-side updates, and add timezone and COALESCE fixes. The migration surfaces utf-8 bugs surfaced and strict-typing failures that were previously silent, but query performance improves (tests and many production queries run two to three times faster) and the production conversion on Christmas morning succeeds with follow-up bug fixes.
AI-written summary · about
chapters (9)
- 0:00Start
- 4:38Data and Scheme Convertion
- 6:16Application Code Changes
- 9:15Automated Changes
- 18:33Manual Changes
- 25:39Production Conversion
- 35:26Success Factors
- 35:39good test coverage
- 37:57Questions
related talks
38mSwitching Teams: Moving an Application from MySQL to PostgreSQL
59mLarge Scale MySQL Migration to PostgreSQL
06mMigration Consideration Oracle to PostgreSQL
45mSQL Server to PostgreSQL: Migration Challenges & Solutions
31mSimplifying the Top Complexities While Migrating From Oracle to PostgreSQL
36mTales from the Postgres Front, and What We Can Learn
24mMigrating from Oracle to Azure Database for PostgreSQL, Seamlessly
22mAccelerating PL/pgSQL Code Conversation When Migrating to Postgres