Sometimes people are annoyed by the term ‘Database DevOps’. Why not call it simply ‘DevOps’? After all, Database DevOps follows the same core principles.
The answer is simple: implementing DevOps is tricky by itself, but most teams are set up to fail when it comes to implementing DevOps for databases. This makes it worth defining as a specialization.
Twenty years ago, database administrators (DBAs) were the primary career path when it came to specializing in data management.
Much has changed: development patterns transformed from Waterfall to Agile, DevOps drives automation and shared ownership of code, and cloud services have made many more kinds of PaaS databases, data lakes, and data lakehouses available to organizations of all sizes.
These changes have introduced new and varied career paths for data folks which have different emphases on skill sets. In this post, I talk through the commonalities and differences between DBAs, Database Reliability Engineers (DBREs), and Data Engineers (DEs). Whether you’re a hiring manager or data professional, it’s worth knowing about these roles.
Have you ever tried to create an object in SQL Server, but it failed due to a missing table, column, or other dependency? If so, you’ve hit a case where SQL Server doesn’t offer ‘deferred name resolution’.
When I woke up today in the UK, Twitter was alive with jokes, hot takes, and sympathy about an email sent out to millions of folks on a contact list for HBO Max featuring the subject line, “Integration Test Email #1”.
One big gotcha that teams often encounter when automating deployments for databases is that it’s difficult (or sometimes impossible) to ensure that all changes to the production database are performed through the automation pipeline.
These out-of-band changes case the production database to “drift” away from the schema as defined in version control.
Many people use entrenched processes for database development that have been in place so long that it’s hard to imagine doing it any other way. In this episode, I share three things that should NOT be normal for database development– but which are incredibly common.
You’re a DBA, and your development team is all-in on doing DevOps, and they want to include the database. Should your DBA team limit the permissions or options for automation? Or should you instead re-think how your two teams work together?
Copyright (c) 2025, Catalyze SQL, LLC; all rights reserved. Opinions expressed on this site are solely those of Kendra Little of Catalyze SQL, LLC. Content policy: Short excerpts of blog posts (3 sentences) may be republished, but longer excerpts and artwork cannot be shared without explicit permission.