One database, four years, three migrations we regret

For its first six years Halden ran on a single relational database. It held every ticket, every customer and every message for twelve thousand companies, and it worked until the night a routine index change locked the busiest table for eleven minutes.

The move to several smaller databases took four years and happened without downtime, but it was not clean. Lucas shares the three migrations he regrets: splitting by feature when the data wanted to be split by customer, a dual-write period that ran eight months too long, and a sharding key chosen before anyone had looked at real query patterns.

He also covers the step that went exactly to plan, a shadow-read harness that compared every query on the old and new systems before a single customer was moved, and why he would build it first next time. Expect diagrams, query plans and honest timelines.

What you will take away

• How to tell whether your data wants to be split by feature, by customer or not at all
• A shadow-read harness design you can adapt to check a migration before moving users
• The warning signs that a dual-write period has gone on too long