Databases
Databases - Love them or hate them, you cannot get away from them. Databases are the heart of most applications, yet many teams casually handle this critical part of the development stack.
Even been in a scenario where someone quickly ran an ALTER TABLE or UPDATE statement directly in production to fix an issue or enable a new feature? Crazy right ? If you have ever handled a critical project, this is a no-no!
While it feels like a quick win, these manual changes rarely:
Get tracked.
Documented.
and Replicated across environments.
Over time, this creates a silent “drift” between development, staging, and production databases, leading to bugs that are hard to reproduce, features that break unpredictably, and an overall loss of trust in the stability of the application.
Sometimes you look at the data and wonder, how is this even possible?
Devs with local DB Copy
If you’ve ever been on a team where every developer has their own database copy. One person adds a column, another drops a constraint, and someone else applies a patch directly in production without telling anyone. Its just chaotic!
When the code moves to staging or higher environments, half of these changes are missing, causing inconsistent data making you wonder how did we even get to this situation, broken deployments, and bugs that seem to appear out of nowhere.
Manual SQL changes are not just risky, they’re unscalable. What we need is a better way to manage database changes: version-controlled, automated, and consistent across all environments.
Pain Points
Let’s get real for a moment. If you’ve been part of any software team working with relational databases, these situations will sound painfully familiar.
The Classic: It works on my machine
A developer adds a new column for a feature (say, status in the users table) directly in their local database and implements a feature.
They don’t document it.
They don’t create a “migration” script.
They push their application code, assuming “Its working fine”.
Yes, Everything works great locally until it reaches staging or production. Suddenly:
Code Review cannot continue(if they follow the Code Review Process).
QA can’t test the feature.
The staging build breaks.
Everyone is scrambling to figure out why.
This single missing column becomes a full-blown blocker.
Quick Data Fixes That Nobody Knows About
Something is off in production data. A user is locked out or an order needs status correction. Instead of going through a migration process, someone runs and update query and “solves“ the problem or alteast thinks so.
And they are not wrong. Yes, It solves the problem. But:
It’s undocumented — no one knows this update happened.
It’s inconsistent — staging and dev don’t reflect this fix.
It’s risky — one fat-fingered query, and you’ve updated 10,000 rows by mistake.
Weeks later, debugging why production data doesn’t match other environments becomes a nightmare.
Why These Scenarios Hurt So Much
Inconsistent environments – Dev, staging, and production drift apart.
Invisible changes – Nobody knows what happened, when, or why.
Risky fixes – No rollback means every manual change is a gamble.
Slowed releases – Time spent chasing database issues instead of shipping features.
This is exactly the problem Liquibase (and similar tools) exist to solve. More about Liquibase in a future blog.
Let's Connect
Hi, I’m Sandeep Gokhale, and I'm passionate about building high-performing teams at my company, Techvito and I write about Technology, People, Processes and some more fun stuff.
One of my life’s missions is to do whatever it takes to build world-class products and deliver exceptional client outcomes.
In case you're looking out for a technology partner to accelerate your business goals with clarity, speed, and quality & security, my team and I are here and more than ready to help you make it happen.
Feel free to connect with me on LinkedIn and Twitter.
Until Next time!
