This blog post is a copy of a post I wrote for SQL Masters Consulting as part of T-SQL Tuesday. The original link can be found here:
If you don’t already follow T-SQL Tuesday on twitter – you should – search for
The blog post was a slight continuation of my last post:
Before I do that though – I want to think about what I was doing 8 years ago. At the time I was working with Object Orientated databases and the company I worked for had just implemented extensive unit testing across our technology stack. I use that word because we had both the database and application code going through unit tests, integration tests and regression tests. Most of which was automated.
It was around this time that I was starting to do more things in SQL Server, namely SQL Server 2005, funny how 7 years later I was still doing some things in SQL Server 2005 – but that is for another blog post…
It was when I came across to the SQL Server world that I realised that 2 things were different:
- Database build/code definitions were not in source control
- Unit testing was almost non-existent
- Automated testing or deployment was also not a common thing
Even now in 2018 I find that when speaking at conferences and I ask the questions:
- Who here uses source control – 60% of hands go up
- Who here puts there database into source control – 50% of those 60% of hands go down…..
- Who here does automated testing across their databases – another 50% of those hands go down
I generally get ~30 people in my sessions so if at best 5 people out of 30 are doing this – we need to change this.
For years people have been discussing both getting our database code into source control and unit testing has been discussed at length during the past 8 years.
So what does this mean for the next 8 years?
I’m on a personal crusade to bring automated testing and DevOPs philosophies to your database…
In fact I am hoping that DevOPs doesn’t exist in 8 years time – we as an industry matured and called it “commonsense“.
Let’s talk about automation – as whilst people might not see the value in testing our most precious resource – data – they will hopefully see the light in that the more we can automate the better our jobs will be.
But won’t it kill the DBA off I hear some of you ask.
In 2026 the role of the DBA will have morphed, in fact all Data Professionals will have an appreciation and understanding of how to automate the delivery of value to the end user. I choose my words carefully – too often we as technical people thing about 1s and 0s but in fact it is how we deliver value to our clients that dictates our success. In terms of customer experience we need to ensure we are delivering value of higher value than our competitors.
Many people are worried that automation will put them out of a job. This won’t happen, and in fact there will never be a shortage of work to do in a successful company. Rather, people are freed up from mindless drudge-work to focus on higher value activities.
This also has the benefit of improving quality, since we humans are at our most error-prone when performing mindless tasks.
By utilising the features in SQL Server Data Tools (SSDT) Version 2026 – which does both State based AND Migration based deployments to databases automatically means that we as DBAs can start focusing on activities that bring value to our clients. Databases have been touted to be self tuning for decades but I simply don’t see it happening and we need DBAs that can tune queries, and more importantly understand how automation can make their lives better.
Data Science is big time in 2026 – the past 8 years have seen a massive jump in it’s usage. This is where Data Professionals have a massive part to play – cleaning up the underlying data – who knows – through automated cleansing jobs that self tune themselves… automatically.
See where I’m going with this — the growth of data we will see over the next 8 years means we need to be more vigilant in the ways that we interact with the data. Using automation and more testing means that the data scientists can focus on what they’re good at – doing stuff with data that they don’t have to spend (up to) 60% of the time trying to cleanse.
I am not scared of automation putting me out of a job, I’m more scared that over the next 8 years that people won’t embrace it enough to help with the delivery of value to the end user.