Database Administrator

You know the weird thing, Kat, I don't know if you've seen this or Bart, you've seen this.

I used to work with a lot of DBAs back in the day, but now there's not that many DBAs that we used to work with.

I think the roles are shifting.

Is this true? And what you're saying, I completely agree with.

Like your platform engineer, that is a DevOps person.

And it was SRE for a while too, right? So like this is just job title shuffling.

That's all that's happening with DBAs.

They exist somewhere in a platform engineering team under a different job title.

Postgres was known throughout the land for its reliability, its powerful features, and most importantly, its generous spirit of open source.

One day, a young DBA embarked on a quest to find the perfect database.

So while he was trying to find the perfect database, he thought, hmm, there's all these features.

this open source stuff, which is the perfect database, right? So he traveled the land.

And he was like, maybe I didn't find that.

And Postgres responded, that's because you hadn't found open source, a true open source community.

So eventually, the DBA decided, I'll join Postgres as a community.

Now, Why? The Postgres community, yes, is open source, but there's a lot of collaboration.

Now, the answers are mixed, especially in the database world where it seems the cost and the value delivered from database management and deployment can be nebulous.

Databases support these applications, and if that software doesn't work well because the database deployment scripts weren't correct, or they weren't tested, or they have performance issues, who is at fault? Now, it's easy to blame the database, but who bears responsibility here? Is it the developers that didn't model the schema well or test the queries at high volumes of data? Is it the DBAs who haven't been adding or maintaining indexes? Is it a lack of resources matching workload, which is kind of an ops issue and a finance issue? Or perhaps somebody's not taking time to review code, right, which is a shared DevOps, or maybe it's a process issue.

Could it be delays from a slow process to actually promote changes to production that delay your digital transformation? Execs really care about that last one.

Now, there are lots of metrics that Dora produces about DevOps and software delivery, and I've linked an article from them in the editorial.

And we have customers from all around the globe on various verticals and sizes.

So you would see those enterprises with many databases that would have DBAs, DBREs, whatever.

So people responsible for databases, but they will also have so many databases that those people will need.

some kind of help.

I was just reading about that leak.

Essentially, on the flip side, you have, you know, these are largely good actors when we talk about developers and DBAs working with their production databases.

They're not intentionally trying to set AI loose and delete stuff.

But like because of mythos and all these other things, like if your code isn't set up securely, if your database isn't configured securely, if you're not following all these best practices, you know, you end up in a situation like Beacon CRM where basically they had put some key in their JavaScript build code and then some bad actor was able to very easily find that.

And so that's been an interesting way that I've seen some shifts in in development.

Yeah, yeah.

You know, when you were talking through adding a new table, immediately just in my mind, the word fact table popped up because there's a whole lot of companies out there where they have super senior expert DBAs who've been doing this for a long time.

But I think there's even more companies and software teams out there where they don't.

Yeah, this is a good question.

What's been super interesting, all of these things emerged so much, so actually you have now a full-stack data guy, right? Before it was like, okay, software engineer, full-stack or something, but on the data or database side, To be honest, I've always tried to avoid DBA stuff, not because I hate it, but for me, it was difficult, not my cup of tea.

Why? Because I think the real value for the business, and you should always think about business and produce some value and create some products.

And of course, someone needs to do a heavy lifting with the infrastructure these days before it was the base stuff.

So mainly it was the use, the data, I find the usage of the data.

In that period of time, it wasn't divide per row, like, okay, I'm ML or data scientist or data engineer or analytics engineer or DBA or infrastructure engineer or DevSecOps or DevOps, whatever.

It was just one guy doing everything, right, from end to end.

And most of the time I was on my own, especially in smaller projects and smaller teams.

So there you go.

Uh, next up, Chomping Bit says, "How do you develop skills that your employer isn't using? Our organization is not embracing the cloud, not embracing PostgreSQL, or any of the skills that are dominating the open DBA roles required skills.

Do you ever find yourself in this spot? How did you make yourself demonstrable skills for the next interview?" I've never personally found myself in that spot.

Um, the, the thing that I would recommend to you is you can't get the experience at home in a lab in a way that's really going to credibly get you the job.

Just like you don't see a lot of classified ads for great lease deals on Porsche 911s or Ferraris.

It's because they don't need to advertise because buyers are lined up for those.

You don't see a whole lot of ads for SQL Server on-premises DBAs because there are lots of those.

The company only needs to put up a brief ad on their website momentarily, and they'll be inundated with requests from people who have dubious qualifications.