LinkedIn Live: All right, so you inherited a bad database...

Back on Friday, July 17th, I joined Courtney from Manning for another LinkedIn Live, this time on what to do when you inherit a bad database. The recording and the slides are now up, with a Q&A at the end.

The session was based on Chapter 11 of my book, PostgreSQL Mistakes and How to Avoid Them (Manning). This one was more of a fireside chat than a technical presentation, and if you know me, I tend to give the latter. It's a situation most people who work with data run into sooner or later, and the first thing worth saying about it is that you are not alone.

These databases come about for what we politely call historical reasons: no DBA on the team when the thing was built, rushed deadlines, organic growth, and various other reasons. There's also a thing I call architect disease, which is architectural arrogance: a data or software architect joins the team and says forget the best practices everyone keeps talking about, I know the perfect way to do this. What they build might work fine for the use case at the moment it rolls out, but people usually have trouble maintaining such designs afterwards. The symptoms are recognizable: improper database encodings, tables with a hundred columns because they were once spreadsheets, missing indexes, no constraints so the data is inconsistent, etc.

The part that matters is that assigning blame is not a strategy. What we covered instead:

• Don't panic. These are solvable problems, and never let a good crisis go to waste: you have effectively been given permission to fix things.
• Ask the humans what hurts. People are keen to complain once they find an outlet, so let them. Beware the XY problem while you listen: when someone asks for partitioning or a Kafka pipeline, find out what they are actually trying to solve before you build it.
• Examine everything: the schema with pg_dump, pgAdmin or DBeaver, and the data with exploratory queries. The configuration, and the behavior, through logs, pg_stat_activity and pg_stat_statements.
• Fix in small projects with measurable goals, one change at a time, documenting as you go. Then automate high availability, disaster recovery and maintenance, and share the guidelines with the whole team: do this alone and you will suffer alone, while everyone carries on as before.
• Stop reacting and start planning. Don't wait for data loss before you take backups, an outage before you plan for high availability, bloat before you tune autovacuum, a billion rows before you partition, or a terrifying cloud bill before you look for what to optimize.

🎞️ Video on YouTube: youtube.com/watch?v=nI1KjJjun3c

📊 View the slides: All right, so you inherited a bad database... (PDF)

Have you inherited one of these and lived to tell the tale? I'd like to hear about it, on Mastodon at @vyruss@fosstodon.org or on Bluesky at @vyruss.org.

Discount code ang35au gets you 35% off all Manning products 👇