I watched Bob Ward demo vector search in SQL Server at the NYC PASS road show in late August, and I have a confession that I’m not proud of. I felt that little knot in my stomach that every DBA knows too well. His pre-recorded PowerPoint videos typed a few commands, asked questions in natural language, and received helpful answers. I thought, “That looked too easy.” Then the second thought came. “I’ll never fully understand this. What am I even going to do with this? Why do we even need DBAs!? That was too easy, and look, he’s speaking in English and the answers are flying back…” The self-preservation instinct kicked in fast. “Meh, not my problem.”
But then the next morning, on the train ride back North, it hit me. It is my problem. It’s everyone’s problem who has ever cared about the quality of data and its users. Because what Bob showed wasn’t just a neat trick. It wasn’t a replacement for the OLTP systems of record. It was another data structure. Another data source. Another shape of data. Another thing that needs to be secured, documented, governed, standardized, backed up, and understood. The same people who have ignored naming conventions, skipped documentation, and left no trace of lineage are about to build vector search databases. And they’re going to go into it thinking it’s minutes of work like the “turkey in the oven” cooking show like demos that Microsoft loves, missing the scores to hundreds of hours that went into building that polished presentation Bob showed. And they’ll get it wrong sometimes, they’ll miss the big questions, they’ll miss the chance to standardize naming, they’ll miss the “itties” of database administration. And that means someone needs to care. Someone needs to steward this new frontier and make sure it works with the rest. That someone is us. The same people who’ve been doing it all along.
Our Calling HAS NOT Changed!
Us DBAs have been called a lot of things over the years. Paranoid control freaks – as I wrote in a blog about it 16 years ago (go easy on me 😉 ). The team that says no. “The reason we can’t do anything around here.” Heck, we proudly wore titles like “GrumpyDBA” or “ScaryDBA” on Twitter or whatever they call it now. We grinned at the sense that DBA really meant “Don’t bother asking…”
We said no because we cared. We still care. We know what the users want because we often are the bridge between the users and the IT teams. We know that once bad data gets loose it never dies. We’ve spent too many hours in “lunch” meetings (to the point I would reply to a marathon meeting invite over lunch with “Mushrooms and peperoni on my pizza and I’m there…”) discussing something like “subscribers are members sort of but patients are not subscribers and persons are not people but insureds generally can be a member but sometimes a dependent can also be a person but never a subscriber unless they came from this system then they are only ever subscribers.” The bad data festers. It lingers. We wore the labels we got with honor – we still do.
It’s not some power trip thing – it’s not the allure of being the only ones with the sysadmin role. It’s because we care. Sure you can joke that it’s really just because you didn’t want to get called at 2AM on vacation with your family. But we care. We care about the database. We care about the data…
Someone has to worry about what a manager early in my career once told me were the “itties of database administration (Reliability, Security, Quality, Availability, Recoverability, Performability – work with me on that one…). That was our job. We worried about restores instead of backups. We worried about staying online for the month-end close. We worried about lazy code and cruddy designs and the worst indexing strategies. It all matters. We were and are the stewards of data. Riders of Rohan – standing guard over a kingdom of information instead of men.
I’ve been that person more times than I can count. I’ve been put on lists by asking the questions in the all-staff meetings where you really weren’t supposed to ask questions.. Like the time I asked the CIO, “Excuse me, why was data quality taken off of the initiatives here in Q4?” and my inability to shut up when the answer back was, “Well, Mike, thanks for asking, that’s because quality is everyone’s responsibility…” I was asking for a reason – and all of the data we were trying to turn into actionable intelligence for the underwriters to make accurate decisions clearly never even lived in the same universe with quality – and I fear may still not all these years later. I wasn’t trying to win an argument or score points – I was trying to save the data from the folks in charge of the data, ostensibly…
That manager who taught me about those “ity” words – he tried to hammer it into my head that we were the last line of defense for the uptime, performance, reliability, and quality of data. Everyone else would break one of the key tenets we cared about in the name of “speed wins” or “progress”. Developers would sacrifice performance to get the code out the door on time (because of how they were measured from above), Infrastructure was being pushed to call us “disk sponges” by the CFO and wanted to sacrific performance for a few less disks. On Availability, they’d ask, “Do you really need two DL585s – I mean, how often will you even have to fail over?!” Vendors? VENDORS?! Pfft don’t even get me started about most of them – they wanted revenue with as little expense as possible 90% of the time. But we were there to keep the nurses able to talk to patients to make real differences in their lives. If the data was slow, wrong, or not there – they weren’t helping patients. Real people. Real impact… When we failed – they failed (ask me sometime about how I learned about dependencies in Failover Clusters – it was there – and that 10-minute downtime was all my fault…)
I’ve left jobs for cuts in pay because I realized that stewardship not only wasn’t possible, but it wasn’t welcome. It was a liability rather than an asset. I didn’t really realize it until that train ride home from NYC – I’ve always cared about the data. The database… SQL Server… That has jsut been the medium I’ve mostly used in my career to do that with.
I’ll tell you sometime about the time I had it out with a chief security officer and a vendor installing the building security software database, and my fight insisting that maybe they shouldn’t even use SA at all, and definitely not with a blank password…. (That goes back – you can’t even do that since, what, SQL Server 2008?)
But that’s the kind of stubbornness that defines our profession. The details are changing before our eyes. The tools have evolved (You ever grow a data file in SQL Server 6.5?!? Ever play with backup devices when you had to???). They are evolving faster now. But I posit that the DBA personality type – that caretaker instinct – the “stewards of the data” – that concept isn’t going away. That can’t go away. That’s what keeps the data safe and helps the users make the best decisions. This coming era? The one that we sometimes get scared about? The data stewards are still needed for it – maybe more than ever…
The Format IS Changing.
Here we are… Our world has always changed… “Self-tuning DBs?!?! Query Store?!?!? CLOUD DBS?!?!?” The only thing that has changed is the pace of that change. Postgres adoption. Snowflake, Databricks, Fabric, BigQuery, DuckDB – all of the new AI-driven data structures and engines like vector databases. Through these changes, though, data is spreading faster than ever. More shapes. More sizes. (more stupid names and buzzwords, too….)
BUT! The operational systems?! They actually aren’t going away. The ERP is still the source system. Instead of just feeding an ODS, a Datamart, a warehouse, and a data lake mart house igloo thing – they are feeding even more processing engines (I don’t even know what term to use – I want to say “Databases” but it isn’t really the right word..) The data still has to maintain the “itties” in the source system. It still has to make its way from that source to the new destinations and do so securely, accurately, and on time. I dare say the security part matters so much more now, also, just like these new approaches are fueling our companies, they are fueling the growing enterprise of “not so nice” people.
It is easy for us DBAs – the old guard – to look at these new systems and feel like outsiders. But the world is learning what we’ve already known all along – data doesn’t just appear… It doesn’t just show up and exist. It has to live somewhere – it moves from company to company, from department to department. It has to follow a growing set of rules. Mistakes have consequences – with big dollars (or worse…) attached. And someone has to make sure it all holds together. Us, The Data Advocates.
AI will not replace us. Not if “us” means data stewards/data advocates. AI will make the rote and mechanical tasks we do faster. It will do some of them for us. It will tune some queries. It will summarize logs and find the needle in the haystack we just honestly aren’t equipped to find. It will even fix some of the dumb problems we spend as many hours complaining about as we waste fixing. It is not about replacing our judgment. It’s not about caring for data more than the DBAs I know care. It won’t become the advocate for the data. The spokesperson for the business user. It’s not going to ask the questions before the crap hits the fan – not the same way we who have been burned so many times will. It will do a semi-decent job of translating business to geek – but it isn’t going to connect the dots the way we always have. The DBA role isn’t dying. It’s evolving. We’re data advocates. And “administering” databases is one of the ways we do that – but it can’t be the only way. The data formats are changing. The calling is not changing.
Why CDO as a Service Fits
That’s why bringing Buck on board, as I mentioned yesterday, is so natural. Having a CDO feels like the most natural next step for us at Straight Path. We aren’t changing who we are. We’re expanding our area of responsibility to what it should have been all along – the data.
Even without my bias, it’s clear to see that we’ve done a wonderful job for our clients. We’ve guarded their SQL Servers (sometimes from the clients themselves!). We’ve restored their oopses, and made sure that we could do the restores when the time was needed. We’ve shaved off countless hours of wasted time with tuning. We’ve made them cloud ready, we’ve migrated them. We’ve convinced them to upgrade. We’ve let our clients sleep peacefully at night. But their data doesn’t just live in SQL Server. And if it does happen to live only there today, it’s only a matter of time before it has to exist somewhere else as well.
Which cloud? Which platform? It’s more than that… How do we govern the same way across all of them? What even is “AI Ready?!” and if it is a thing, how do we know we are? What is data lineage? How do we keep the same approach in the myriad places our data is copied and moved to? What about compliance? What do we do when the CEO sees a Bob Ward demo and wants that tomorrow?!
Those aren’t technical questions only. They are stewardship questions – data advocacy questions. It has always been about the data. I just own too many SQL Server shirts from conferences to realize that it’s been the data I’ve cared about all along. Relational DBAs aren’t going away anytime soon – but I bet your company will need fewer of them as the automation ramps up. We aren’t even going the way of COBOL developers and mainframe engineers (who are still plentiful) – but a change is coming. Be a data advocate. Learn with us. Join or (watch your career) die.
The growth and learning we are about to experience with Buck is really just formalizing something we’ve already been doing in spirit. That caretaker/steward ethos is evolving into a proper service offering, and we’re focusing on what truly matters. It’s the data….
The Age of Data Advocates has Begun…
When I think about where the data world is going, I can’t see an end in sight. I see a bigger landscape. I see more threats to the things we care about. The databases are still here. They’ll always be here. They’ll just be joined by these new formats, models, and engines. The data still needs stewardship – and those stewards need to understand that full data landscape.
I don’t think this is the end of the age of the DBA. But it is the beginning of the age of Data Advocates. The armor is now lighter, and some battles are fought on our behalf with the aid of automation and new technology. But the battlefield is wider and more “dynamic”. There are threats we haven’t even imagined yet. The watch continues. Because someone still has to stand for the data.
And if you’re a DBA who gets why “ScaryDBA” made sense for a Twitter handle and blog for Grant when he landed on it, you already know that. It’s what we’ve always done.
“A Promise (I hope)”
While Buck will be reporting to me, and I’ll sign his paycheck, I’ll feel woefully inadequate in telling him what to do and demanding it always be just as I ask – it’s not my style anyway. However, I don’t want to build this data advocacy as a Standalone island quietly inside of Straight Path. Sure, I want to grow as a company and we have some revenue to protect – but I want to be as transparent as we can. I want to see an army of data advocates out there mixing up tools and techniques to care of the data. It’s a wicked awesome time to be a data professional. And the future isn’t scary. However, you must learn, grow, and adapt. And you have to remember the data is what matters. It’s why we have jobs that for the most part we all love. Join the data advocacy revolution.
FOR DATA!
