Every few years, something comes along that's definitively, no-questions-asked going to replace us.
Let's review the historical record.
A Brief History of DBA Extinction Events
1996: Larry Ellison announces Oracle 8i and "lauds its self-managing capabilities as being the death of the DBA."
— Claremont
2017: Larry Ellison unveils Oracle Autonomous Database: "a totally automated 'self-driving' system that does not require human beings to manage or tune the database."
— Claremont
2020: A DBA reports from job interviews: "The interviewer in both cases said 'we don't have a DBA, our databases are in the cloud and an upgrade is as easy as pushing a button and requires no downtime.'"
— SolarWinds
2022: Matthieu Cornillon, Database Tech Leader at ADEO: "The DBA is dead... The job we knew is dead, and there's no doubt about it. Automation and the cloud made sure of it."
— Medium
2023: Larry Ellison doubles down: "The Oracle Autonomous Database is self-driving because it has an AI module that is the DBA. We replaced the DBAs with AI."
— Cloud Wars
And yet. Here we are. Still employed. Still getting paged at 2 AM. Still explaining to developers why SELECT * in production is a bad idea.
What Actually Happened
Every one of those technologies became part of the toolkit. GUIs made administration faster. Cloud made provisioning easier. NoSQL found its niche. Serverless handles specific workloads beautifully.
None of them eliminated the need for someone who actually understands what's happening under the hood.
AI will be the same.
The Job Description Is Changing (Again)
Here's what I've noticed in the past year:
The DBAs who treat Copilot like a threat are spending their energy on resistance. The DBAs who treat it like a junior team member are getting more done.
Think about it. A junior DBA who:
- Responds instantly
- Doesn't complain
- Knows every syntax variation you've forgotten
- Still needs supervision on the big stuff
- Will confidently give you wrong answers if you don't check the work
Sound familiar? That's every junior DBA you've ever trained. The only difference is this one doesn't take days off.
The Skills That Matter More Now
Judgment. Knowing which solution fits the actual problem. Copilot can generate five different approaches; you have to know which one won't crater production.
Context. Understanding the business, the workload patterns, the history of why things are the way they are. AI can't attend your architecture meetings.
Accountability. When the query Copilot suggested locks up the database, someone has to fix it -- and it won't be the chatbot.
Communication. Translating between business requirements and technical implementation. Being the one who explains why those warnings shouldn't wait until they become outages.
These are the skills that were always valuable. They're just more visible now that the routine work is being automated.
The Good & the Bad
AI won't replace good DBAs.
But I'm betting it will expose those who were mostly doing work that AI can now do faster.
If your value proposition was 'I know the syntax and I can write basic queries', you have a problem. That was never enough — it's just more obvious now.
If your value proposition is 'I understand the systems, I make good decisions under pressure, and I can solve problems that don't have Stack Overflow answers', you're fine. Better than fine, actually. You now have a tireless assistant for the boring parts.
My Prediction
Five years from now, we'll look back at the AI panic of 2025 the same way we now look back at the cloud panic of 2010.
Some jobs changed. Some people adapted. The ones who leaned in came out ahead.
The robots aren't taking our jobs. They're just making it more clear what our jobs actually are.
Thank you for this post. I look forward to the next one (even if it is automated.)
ReplyDeleteDefinitely not automated... yet. These things take time. Glad you liked it!
Deletewow, I loved the content. Thanks for the clear picture with a clause to introspect where are we standing as a DBA.
ReplyDeleteThank you! Anyone who can work "clause" into a compliment. Spoken like a true DBA. ;)
DeleteThank you for writing this post, this tell us where are we as a DBA.
ReplyDeleteMy pleasure!
DeleteThere is still cobol devs out there. We will be fine :)
ReplyDeleteCOBOL was supposed to die in the 90s. It's still running banks. I like our odds.
DeleteI've been working as an independent DBA for 30 years. My oldest client dates back to 2006 and continues to add new companies, new branches, and new developments. In other words, it's growing. They're in the cloud, all the users, managers, etc., are familiar with AI, yet three or four times a week my phone rings with a message from one of the users: "Luis, I have a problem." BTW: Excellent article.
ReplyDeleteThat phone call is the whole point. The technology changes, the call stays the same -- and for now, someone still has to answer the phone. Congrats on the 30 years!
DeleteSpot on. One thing I'd add in the timeline is the advent of NoSQL, specifically Mongo. What they did, around say 2009ish is they marketed specifically to businesses that were TIRED of DBAs being drag on getting business initiatives. Specifically,
ReplyDelete* you don't need a DBA. That was proved false pretty quickly. Mongo is not self-tuning. You do need to pay attention to the partitioning, sharding, and indexing.
* you don't need backups (if the data is sharded). This conflates HA with DR very dramatically.
* you don't need defined schema. the schema is versionable and discoverable over time. This was disproved after a few years when folks realized that you have to have a schema managed somewhere, whether you do it with the database and constraints or you do it via a bunch of code at the "read" tier.
The non-verbal was always "no DBA needed". And they viewed the DBA much like most business stakeholders viewed the DBA: drag on getting initiatives done quickly. This was a huge selling point. It's not a money-saving argument, it's an argument about better time-to-value. Devs embraced this because they viewed the DBA as drag on getting schemas modified to support new features. This is also why devs tend to LOVE json and xml columns...they can change the schema at will without going thru a DBA review board.
THIS is the real reason why the "Death of the DBA" is such an on-going theme. And it's a shame. Because most of the bad taste the stakeholders have towards the DBA role are overcome when DBAs are less dogmatic about what they do. IF I'm right and the DBA is often viewed as "innovation drag" then DBAs need to fix this perception. Fact is, we can evolve schemas to support new business needs without a bunch of fanfare.
This is the comment I wish I'd written. 'Innovation drag' is exactly how stakeholders see us — and you're right that it's on us to fix that perception. The DBA who says 'no' without offering a path forward is the DBA who is ignored. Appreciate you adding this.
DeleteVery thoughtful, It cleared my confusion in my head. Thank you!
ReplyDeleteMy pleasure. Thanks for reading!
DeleteHello i just took a job as DBA where developers did DBA tasks, management finally realized that they need a DBA anyway it is SQL Database with 180 databases all on the same server reference each other, what a mess, now they are asking me to organize it . Yes you do not need DBA it is not difficult to create the table and inserts data but then db starts running slow nobody know what to do
ReplyDelete180 databases on one server, all referencing each other? You're not cleaning up — you're doing archaeology. Good luck, and I mean that sincerely. Let me know if I can help.
Delete"Knows every syntax variation you've forgotten" Ahhh, that is the rub. Particually with ORACLE. I remember 8i - Version 8 for the internet before Grid. Still employed.
ReplyDeleteStill answering the question AI can not because no one has feed *our* database in. Nor has anyone fed the hall way conversations about how to link the tables into A.I.
Like "Peperage Farms - I remember" why the tables have a three letter prefix and what each group means. [Never did document that part]
'Never did document that part' — and there it is. AI can't attend the hallway conversation from 2009 where someone explained why those prefixes exist. Institutional memory isn't in the training data.
DeleteI think it goes back even further. Oracle 7's optimizer was touted as being the end of DBA needing to optimize queries. Back in the good old days when tables went in a query in their most selective order. Our system dragged and we switched it back to the V6 compatibility.
ReplyDeleteBut the system that got no love ran faster because for code that was almost untuned yes the optimizer was better than people who didn't know how the engine worked.
Oracle 7! Now we're talking history. You've made the point better than I did — the optimizer was better than people who didn't know the engine, but never replaced the ones who did. Same pattern, different decade.
DeleteThank you for this insight . Love the reference to the cloud panic and so true
ReplyDeleteThanks! Turns out the cloud panic was mostly vapor.
Delete"Sound familiar? That's every junior DBA you've ever trained. The only difference is this one doesn't take days off." This is part of the problem. What happens to the supply of junior DBAs when companies no longer have an incentive to hire them. Senior DBAs retire, and all that's left are the machines.
ReplyDeleteVery good question -- and I don't have a tidy answer. If companies stop hiring juniors because AI handles the entry-level work, where does the next generation of senior DBAs come from?
DeleteThanks for the article, I'm embracing AI... I treat it like a rubber ducky that can answer back!
ReplyDeleteha! Perfect analogy. Though I'd say it's more like a rubber ducky that thinks it can answer back. Sometimes brilliantly, sometimes with the confidence of a junior who just discovered cursors. The key is knowing when to trust the duck.
DeleteNo, seriously, you DO NOT need a DBA.
ReplyDelete*IF* your data has no value to the business. And, if it doesn't - why are you even bothering to store it in the first place.
On the other hand, if your data does have value, and it is important, then - just like your finances, better have a specialist responsible for it. Because when push comes to shove, SOMEONE is going to be responsible when it all goes pecs up, and that person is, at least, going to be the person who decided it wasn't required, which is going to be very painful for them, or everyone at the company - which is very, very painful for all concerned.
Exactly. The 'you don't need a DBA' crowd usually hasn't had the conversation yet about who's responsible when it all goes sideways. Data has value — or it doesn't belong in a database.
Delete