I went to my first SQL Saturday this past weekend up in Maine, the first session I attended was on Best Practices for database deployments, it got me thinking about transitioning from more of a Production Support DBA in an IT organization to the DevOps DBA in an Engineering role I’ve take up over the past few years, though I don’t think the differences are quite as big as some may think.  For one, the production support aspect never goes away, though a lot of that may be from working with small to mid-size companies.  I’m still on call, things still need to be up & running.

The biggest change for me seems more around the size of the changes coming in, being in an Agile environment drives much of this, but also being part of an engineering environment versus implementing off the shelf applications from outside vendors.  There is still a review on what changes are coming in, but in the IT organization, these were managed as projects, and some applications may go years between vendor updates.  Depending on the application there can be a massive amount of schema/data changes, often times this was a negotiated downtime event, coordinating the app & database updates.  Depends on the application.

In this agile setup, many of the database changes are fairly small & straightforward to review, sometimes a simple as adding a single column, index etc.  Since it’s an internal development, we can mandate that all changes are backwards compatible, so that database changes can be deployed independently of the application change, giving us time to “bake in” the change, make sure there are no negative impacts.  These database changes happen up to a few times a week, depending on the component being deployed.  They are uptime changes for the most part, often during business hours – +1 for minimizing weekend work.

Database tuning is a necessity on both sides, though larger vendors may have configuration setting recommendations required.  When SQL tuning, often the only option I had was to add indexes (outside of additional tuning on the instance configurations).  With an internal development team, there is some more flexibility (To a degree – when devs use ORMs like Hibernate or Active Record, adding indexes is still more straightforward for SQL tuning – but SQL can be rewritten in a better manner than created by the tools, but you lose some of the benefit of using the tool for managing your code in the first place).  But there is more of an opportunity to address sql rewrites for performance tuning in house, versus working with an external vendor to address their code.