If you can model data, build data warehouses, manage and maintain schemas, and help analysts write effective SQL; you'll be employed for a very long time. If your entire focus is on the system administration perspective, that career is quickly disappearing in favor of SaaS/PaaS solutions.
Whilst the word quickly is subjective, I haven’t seen anyone roll out Oracle for about 15 years vs literally hundreds of Snowflake, Redshift, RDS, Elastic cloud deployments.
Maybe OLTP is moving to SaaS slower, but the on prem data warehouse market must be dying a death?
Yes there are very few Oracle rollouts but there are still plenty of on prem MySQL, PostgreSQL and MS SQL rollouts. Yes, there is a lot more cloud today, but I feel Oracle really is the product hit the hardest.
There is noSql solutions being built, but when I left a couple of years ago there were Oracle database backed projects in flight.
Some of the 3rd party applications supported PostGres so they didn't even need to stick with Oracle, but they did. It was when management pushed for a project to be Oracle back that caused a few of us to quit. It's nasty enough to develop on, I don't want to support too.
I'm located on the opposite side of the world with respect to Silicon Valley, and admin jobs are disappearing quickly here. This may surprise you but we have heard about this "cloud" thingy. ;-)
But the question is, would you like to get a job at those companies relying on outdated processes where you take care of a pet server? Maybe even running on an old flavour of proprietary UNIX?
It's like every fashion fad in IT: stuff hits, everybody goes gaga over the toy examples until it's time to put it in production. Then they finally find out what kind of a dumpster trash fire the newfangled fashion fad is, and start looking at tried and true technologies. It's always the same.
Yeah, and everyone is trying to normalize their mongo schema. The only thing the cloud got us is faster provisioning, and perhaps greater reliability due to that. It didn't magically solve scalability and integrity.
Both at the former working place and the actual working place we use SQL as the major part of our data storage strategy for microservice based apps. We also use NoSQL but will never give up on SQL.
I agree with the cloud and to some extent containerisation, however I don't think NoSQL and microservices "won". Over past couple of years I'm seeing a huge move away from NoSQL and renewed interest in SQL databases in general and Postgres in particular. The same with microservices. I've seen several projects that went all in on microservices a few years go slowly backing away from the approach, as well as newer projects that are being much more cautious with taking a micro service approach to their architecture.
Ah yes, the magic cloud where you don't need to lift a finger and everything is safe and works and everybody is having a good time!
The only ways I have seen admin jobs disappearing is that they're renamed to "DevOps Engineer" or a company starts in a magic cloud with no admins and devs doing everything which more often than not turns into a dumpster fire and then they start searching for admins.
You may need less people to manage the cloud but someone certainly has to manage it. Unless someone has a specific responsibility to manage infra or someone personally cares about those things then things go unchecked, ports open to the internet that shouldn't be, no backups, etc., devs are usually concerned with making their app work and not those things.
And this isn't a knock on developers, there's only so much info you can retain and focus on so many things on a day to day basis that there's a need for people to specialize in certain areas.
As a former DBA I agree. And this was the fun part of the job. The provisioning databases, installing updates, configuring, doing backups, etc., that’s all automated by any decent cloud provider. And that part is no longer necessary unless the place you work at insists on rolling their own DB instances instead of a managed provider.
A bit more nuance I'd throw on it is to a Data Architect. While databases are a primary storage system, knowing data modeling / systems in general is beneficial and leads to a broader role / career.
Not sure if I agree about which role is disappearing when, but it does highlight the two types of DBA:
- the "Dev DBA" who makes sure ER diagrams are constructed sensibly, knows how to look at an explain plan to see where queries are going wrong, maybe even the odd stored proc (heresy!)
- the "Sys Admin DBA" who makes sure the database has enough space, rollback segments are big enough etc etc.
For a potentially non-indicative view: I grew up in the modern software era, whatever that means to you (frameworks, kubernetes, 500mb react web apps) and have a lot of hiring authority myself and have a lot of cross functional experience, including SRE and working in an actual data center (so loud). imo DBA is useful at the extreme edges of performance after product market fit has been found and 90% of software has been written and it’s time to optimize. I wouldn’t personally hire a DBA before that as it would be premature optimization, especially considering “modern” approaches to profiling queries. I expect my entire team of SWEs to have profiled any DB queries and found low hanging fruits, and also lean towards fully managed database services like RDS.
That being said, that’s a startup opinion. There are lots of F500s that will want them in their data centers. So like cobol programmers, I don’t think there will be a problem getting employment somewhere in the foreseeable future.
I worked with a dba around 14 years ago, and then again in 2016. Those were both at corporate jobs. Other than that I've worked for small businesses, start ups and as a contractor and that's all been fullstack. I think specialized roles make for better software and small teams trying to support the whole stack with their javascript bootcamp training are the biggest reason so much tech is absolute garbage these days.
So I hope you find from other people that this is still a good role to pursue and that you do become a dba and work as a specialist with highly skilled teams and make the code world a better place.
For instance we have the EV boom, and visibly a lot of companies are rushing in to try to make as much as they can without planning for what they would do if they become the next Toyota. But surely, some are planning a bit more ahead (or have a more long term viable approach, even if by accident), and time will tell who they are.
My glass half full view would be that we don't need most companies to succeed, as long as the well isn't poisoned.
In the beginning, if you wanted a computer, you had to design and build it yourself. You had to be an expert in electronics and computer science to do it. And back then, there were no computer parts. You had to manufacture everything yourself from vacuum tubes. Once you were done, you would have a tiny amount of memory and processing power to work with, meaning that you had to be an expert programmer to take advantage of that tiny processing power. And, there were no stored programs. Your program was implemented as an arrangement of cables on a plugboard, something that was error prone and time consuming.
There were no compilers or interpreters for your code therefore no compiler errors, no runtime errors, no debugger, no anything. If things didn't work, they just didn't work and some types of mistakes would have disastrous effects on the hardware.
Now, you don't need any of that. Yet, you can call yourself "full stack". No one truly full stack anymore.
no one is saying to take it back to assembly, but at least maybe try to understand how asynchronous code works if you're going to try to program professional applications in Javascript.
I am self-taught and cringe when i think back to my early days because I knew so little and didn't realize it. I've never attended any CS courses and learned everything I know from putting in almost constant work on the side (I mean this literally, I almost only work on creative projects with all of my spare time) -- but I can't overstate how much I learned from people on the job as well, they propelled me to new heights.
All this is to say: I don't begrudge newcomers and have always tried to give back more than what I got from others when I was Jr...
But good lord bootcamps do not produce much in the way of talent in my experience. I'm sure there are some shining stars that benefited, but I have yet to meet one of them. One guy I worked with fully admitted to me in private that he plagiarized his "final" for bootcamp which was a rather difficult algorithm. He just used some open source code he found on github and only slightly modified it. The code he wrote that I had to support was some of the worst spaghetti I've had to pick apart and fix and he was the lead engineer for the company.
These companies would make more money with proper talent. Code camps need to go away.
I've worked with many bootcampers and all but one have been fantastic. And the one wasn't bad because of arrogance or deception; they were a super nice person with plenty of integrity. They were bad at their job because they simply had no feel for programming, and would have been just as bad if they'd had a CS degree.
Bootcamps are like anything: you get out what you put in. They are a(n often effective!) way of learning a skill. If there's a problem, it's with tech hiring and its ability to accurately evaluate candidates. But that's an intrinsically hard task, and I don't know if there's a real solution (and the inaccuracy cuts both ways, and affects everyone, regardless of where they learned to code).
Stop inflating your own narrow experience and projecting it onto a huge swath of people. Pushing stereotypes is harmful.
I gave an anecdote mentioning one shitty individual who would likely do shitty things even as a proper CS student yes. Beyond that I'm dissing the form of education, not the individual human. Maybe they're "nice" people but if they are leading a team of engineers right out of bootcamp, you're gonna have a bad time (and I've seen this happen in at least one occasion as I mentioned).
Looking back over this hours later I want to add the following:
the anecdote I offered above was not an effort to paint code camp participants as untrustworthy or incompetent. My point is that this individual was lacking in skills and knowledge beyond a Jr level engineer and plagiarized at least part of his codecamp work.
The only thing he needed codecamp for was the "education" on his resume and a shortcut through the interview process. He was made lead engineer, potentially just to boost his resume, but regardless he was involved in "fullstack" development which was leading to some really really nasty issues. He had already worked there for some time once I joined the team, so I have no idea how limited his skills or knowledge were when he joined. What I did see was that he took a codecamp shortcut. This is harder to do with college CS courses and totally pointless if you're doing it for the fun of learning and creating things in the first place (which is the motivation for my and many other people's self-education).
I've worked with self, college and bootcamp educated people. To reiterate I PERSONALLY have not encountered someone from bootcamp who was beyond Jr level. I'm sure there are people out there who are very talented and have used bootcamp education to their benefit, but I see it as an easy system to abuse and I'm skeptical over the actual educational benefits offered by these schools.
I would also like to add that I have worked for a number of companies who refuse to even look at a resume from people with codecamp education (hiring people who are self-educated over codecamp educated even). I think this is a heavy handed approach and disagree with it.
Regardless of the source of education, loading up your company with people who are only Jr to Mid level is a recipe for disaster.
You are so right. People now in the industry know the mechanism of money and capital much better than software.
But as a software engineer who loves the technology and products that we can build from it, I would really appreciate real DBAs with in-depth skills. After all, databases are essential, and we need experts.
Shady. The worst ive seen is forcing your American staff to hire a massive overseas team at approx $10k per employee per year, having them set up a local company in their country with the understanding that it's just a front and you are their only client, force them to work during American hours and forcing all of your American employees to remote train them for two years and then firing your American staff. Had this happen to me once.
I hate to imagine how many startups out there don't even create indexes and just consider it to be a database problem and increase CPU/RAM and look the other way.
I worked for several years at a semi-startup as a Database Engineer where my role was to guide developers in writing performant SQL (and writing indexes for them) and architect their schema to be inline with our future plans and various other database tasks (managing query plans, being an expert on the database feature set etc). I even created an internal course: SQL School, that I included the directors/customer support teams in.
To that specific company my role was priceless, new features could be built in 1/2 the time with an expert writing the queries and handling the database. My programmatic analysis of our 20 year old code base had 5000 unique queries and 3000 more when accounting for dynamic SQL. Not gonna lie it was a complete mess but if I didn't exist they would have needed a lot more database resources. It was a terrible code base and any plan to refactor and avoid this mess would still need my role to do the transition.
I loved that job but its extremely hard to transition to any other roles and nowadays its easier to use alternative solutions.
My experience is that almost any startup needs to write some complex SQL and has to deal with slow query performance, so at least one or two engineers tend to be good at SQL/databases/query plans/indexing/etc. They may not be as knowledgeable or useful as a full dedicated Database Engineer/DBA, but at least you have indices/someone who enjoys writing SQL/someone who thinks about query performance.
You would think! But during my years as a cloud consultant I was parachuted into a problem project. I observed a large well paid team doing weird shit like archiving all their data to keep their database fast.
It’s interesting that nobody there thinks: “There are much larger companies out there not archiving their data every month, what solution are they using?”
and we must note that the business side did eventually bring in external consultants because the project was clearly distressed. So it did eventually get corrected and I naturally tend to see the worse examples of this kind of thing, but yeah, it is possible to assemble a team of 8 developers and get unlucky such that not a single one knows anything about indexes or cloud databases in general.
I think it’s ridiculous since I come from an era where it was considered basic knowledge. I can’t imagine a software engineer that doesn’t have a passing familiarity with the goals of indexes (even if they don’t know exactly how they work).
But that’s turning out to be more and more untrue. Newer engineers really do not know.
If you have a mission critical database with a lot of writing to it and the requirement of millisecond response times then every index you implement needs to be balanced against the cost of writing.
Like other database objects, i.e. constraints and triggers that's absolutely a DBA job.
> hate to imagine how many startups out there don't even create indexes and just consider it to be a database problem and increase CPU/RAM
I've worked for a few of those fairly recently. I also worked for a place that was running on a fully custom codebase, no framework, php with all sql scattered through each page and all the devs using their individual machines to ssh into a central dev computer to work (tell people which file you're working on first). No version control of course.
This is an automatic fail for an employer. In interviews I ask, if it comes up I interrupt the discussion, verify, and if they truly develop without valid source control/revision control - I end the interview and inform the recruiter NFW and why.
> small teams trying to support the whole stack with their javascript bootcamp training are the biggest reason so much tech is absolute garbage these days
The lazy stereotyping is inaccurate, caustic, and uncalled-for. I've worked with several bootcampers, and nearly all of them have been entirely capable.
I think it depends. I've seen bootcampers who are motivated by being a Software Engineer at FAANG on 500k yet they don't understand why turning off your computer stops programs from running. But I've also met bootcampers who spent several years writing bots for runescape or coding in their spare time and are using the bootcamps as a way in to the industry.
Which just supports the point that the stereotype doesn't hold up, and only serves to discourage and exclude capable people who may already have impostor-syndrome.
I'd argue the years writing bots and coding in their spare time are what benefited them and the bootcamps just helped them pass the interview... which is exactly the same thing I've been saying in all my comments already.
I've contested in a separate comment that there are likely some talented individuals who took a boot camp course. Really doesn't say much for bootcamps though. My anecdotal experiences differ from your anecdotal experiences. My experience has been that people were trained to pass interviews not keep jobs.
The difference is that I'm not claiming bootcampers are broadly exceptional, either; I'm saying I don't have enough data to tell you whether or not someone will be a good engineer based on whether or not they went to a bootcamp. I know my anecdotes are limited, and I'm not trying to make broad statements based on them.
I'm speaking less about the individual and more about the method of education. I don't think someone should go from zero experience, to 6 or 12 month bootcamp, to lead engineer at their first job. Something very wrong with "the industry" as this is becoming more typical in recent years from what I've experienced.
And to that I would argue: that's a hiring problem, not a learning problem.
Based on my anecdotes (I guess I am getting into drawing broad conclusions now), good bootcamps are a good way to turn someone into an entry-level engineer who's equipped to start contributing value and then learn more as they go. If they got hired immediately as a lead engineer and weren't ready for it (which they wouldn't be, if the bootcamp was their only experience), that's the company's problem.
I would add too that there's a huge gap in quality between the best and the worst bootcamps; there are some that consistently crank out totally capable junior engineers, but I've read horror stories about others that are outright scams. It's possible we need an accreditation process of some sort.
But now I feel like we've got to review my original statement. I don't believe I ever said people who went to bootcamp shouldn't be hired or anything to that effect... I think that small teams (often made of bootcampers with relatively no experience) are disastrous.
One Jr Dev won't take down the ship but a whole crew of Jr's with senior titles and authority will at least slow you down to a crawl. In recent years I've worked with teams who are largely made of bootcampers and Jr devs. As I've said from the start, I've been in startup land for a long time now and it's usually all about getting by on a shoestring. I fully understand the financial reasoning behind it, but I dont think the people running these companies have thought far enough ahead and I strongly doubt that any of the places I've worked in recent years will be around even 4 years from now.
Additionally, that Jr dev could have learned to code in their basement from some books for all I care... or could have graduated bootcamp sure. It doesn't matter where they got their info as long as they know what they're doing... but from what I've seen, bootcamp alone does a really poor job producing people who know what they're doing... worse so than college because it's meant to be lightening fast education and job placement.
> but I dont think the people running these companies have thought far enough ahead
Ah hah! Now we're getting to what could be the heart of the issue: short-term business practices, the incentives that drive them, and the market conditions that make it hard to find or afford the necessary technical leadership. This is a complex topic and out of scope, but it feels like a truer source of the problems you've witnessed.
> but from what I've seen, bootcamp alone does a really poor job producing people who know what they're doing... worse so than college because it's meant to be lightening fast education and job placement
It's fair to report that as your experience (even though my experience differs). The issue I took at the top of the thread was with broad, incendiary statements like this:
> small teams trying to support the whole stack with their javascript bootcamp training are the biggest reason so much tech is absolute garbage these days
This is a pile of tropes, capped off with a bold assertion. Bootcamps aren't even especially focused on JavaScript; the ones I'm familiar with also let students pick Python or Ruby for their projects, and also teach the basics of how to use a database and other technologies (of course they don't make you an expert at any of these things). But it was used here because "JavaScript" has become a stand-in in the context of Hacker News comment sections where people are complaining about perceived poor engineering practices. Like "bootcamps", it's come to paint a particular picture in people's heads of a particular kind of dev, whether or not the thing itself is directly relevant to the discussion at hand. Leaning on (and entrenching) these stereotypes is what I'm pushing back against. They aren't accurate, and they encourage certain devs to be disparaged for no good reason.
I think you're missing the point of the comment. There is no judgement on their capability there, merely an observation that a JS bootcamp probably doesn't adequately prepare you to manage a typical startup's entire tech stack, and if you try to do so with only that training/experience, the result might not be very good quality.
As a database engine developer (before single service, now cloud service), it seems that we keep making more specific purpose DB engines that are highly tuned to specific workloads, and take care of scaling, backup, etc. automatically on our end.
Our "customer" is the developer or cloud system architect.
I've not seen many 100% DBA roles except at "large" businesses (though, to be fair, I've only had 3 professional IT salary jobs in 12 years)... And it's arguable to say the people I'm thinking of are 100% DBA... The one that comes to mind best as "100% dba" was responsible for working with devs to improve queries, work with auditors, help manage deployment of certificates (not just DB related certs), and monitor DBs for unusually activity... On top of typical backups, migrations etc.
I would likely not suggest a "DBA" as a career, but it is a very valuable skill set... To get a job at anywhere but a large business... I feel you need one other hat at least.
This isn’t a value judgment on database administration, just an anecdote:
I’ve worked at 5 small companies in the last 15 years, and freelanced for a few years. The dev team size was: (15, 5, 5, 4, 8). None of those companies had a DBA. One company we had a full time IT/sysadmin, but otherwise that role was filled by people with a title like “software engineer”.
In truth, I think we often would have benefited from the expertise of a DBA, but we never made the decision to hire someone for that role full time.
The role is called data engineer now. It's just one of many data engineering roles. Data engineers at a non-tech company could be 1 person holding up the entire system doing administrative tasks on it so to speak. It could also be one of many persons that work towards holding up Youtube's ML recommender systems.
I think just in general data engineer is a better term to find the same role across a lot of companies today.
Glancing at the DBA jobs in a job search engine, you're going to be a functionary at some non-tech business like a hospital or university. Which is fine, it's just kinda on that old school IT side of the business.
I’ve never worked with a DBA. The DBAs I do know are doing valuable and meaningful work. I agree with several other comments highlighting the org size distinction.
Do you like the work? Do you want to work in large orgs? Keep doing it! If you don’t, there’s plenty of room to branch out and I assure you if you’re half decent at the job your insights will translate well to many other meaningful contributions.
A few years ago I have worked with people 100% focused on making the best out of our Postgres databases, but I wouldn't expect that specific scope to still exist outside of huge organizations.
Today I think a "DBA" in a small/middle sized company would be also touching cloud resources and data funneled through analytics and other sources. Basically the "big data" fad we had a while ago becoming just "data", and that data has to be administered, optimized, and backend/frontend devs also need guidance and education on how to best deal with it.
In general, I have the feeling "administrator" roles are disappearing to be either more specific in the biggest orgs, or way broader in the middle sizes/run of the mill orgs.
I hope not. We need to hire a Postgres DBA at Fivetran, we have more or less a single Postgres database with all our state, and it’s become clear that we need a full time person to optimize it.
> more or less a single Postgres database with all our state
oh that’s neat. As a data architect, I like to avoid such issues by never letting it happen in the first place. I love Postie but I’m not a specialist. But why not sharding? Seems like a proper data model in 5Tran’s domain would be intrinsically shard-able by client and you could balance it over multiple instances. Does profiling or analyze expose any low-hanging fruit to pluck off for optimization? Or maybe that’s exactly the question you need an experienced Postgres DBA to ask and answer for you...
I've been a DBA contractor for both Oracle and IBM DB2 for telcos and insurance companies. In my experience, you need to cope with lots of politics and the bureaucracy of large organizations. I also found that you also need to keep your vendor certifications current in order to secure contracts.
We had a DBA about 6 years ago, he was one of the smartest guys I've ever worked with, and knew his stuff inside and out. I would recommend a DBA highly to anyone having growth issues. I honestly don't think we would have scaled without him. I learned a ton from him.
He got let go for basically having a really bad temper, and we decided not to look for a new DBA. I was sad he was gone but also glad to not be getting screamed at. It feels silly, but I've got really unresolved and mixed feelings about the whole thing. I genuinely really liked the guy, loved talking music and movies with him, but he would heel turn in an instant and just ruin your day.
Honestly wish we had a DBA, I ended up picking up a lot of his responsibilities. I'd love to have someone I could learn from. Basically, I'm getting real sick of optimizing reports.
The impact that you describe very broadly reminds me of https://en.wikipedia.org/wiki/Stockholm_syndrome. I'm still learning about the subject, so the only nearby useful axis point I'm aware of is the concept of chronic trauma, which I'm surprisingly unable to find a synopsis on in Wikipedia (the closest I can find is https://en.wikipedia.org/wiki/Complex_post-traumatic_stress_..., which is vaguely in the ballpark but a couple notches too far).
Personality disorders have the potential to have the same sort of impact as water on a rock over time. I wonder how this person impacted other people at the company - and whether the boundary-defying nature of this sort of problem caused the line between "broken individual" and "DBAs are scary" to be blurred.
It could be very interesting for the various decisionmakers to wind up in a conversation with a good psychologist (psychiatrist?) who might be able to make that line a little bit clearer for everyone (and provide closure) and perhaps even outline ways to screen for this sort of thing happening in the future - which may be the speedbump everyone's (very quietly) stuck at.
Honestly I think it’s most akin to an abusive relationship. You love the person for their good parts/periods, but the bad in reality outweighs the good.
It's a bad idea to start pathologizing bad behavior. The vast majority of assholes are just assholes, with no pathological reason for their shitty behavior. It also stigmatizes those with actual medical problems because "being an asshole" isn't a symptom of any disorder you've listed, yet the association is still being reinforced by comments like this.
This is strange and funny to read; the only two DBAs I’ve worked with matched this description perfectly.
The first guy was so irate and literally yelling about his entitlement to punish us for making bad architectural decisions that I thought he was joking. I just laughed, but he got angrier. Then it clicked after maybe five or ten seconds – he was in the process of verbally punishing us for querying the database too much.
The second guy was similar, but didn’t yell. Still super protective of his domain, almost antagonistic about us integrating with the database at all.
Both brilliant, taught me more than I can recount here, hilarious and interesting… But total jerks too, and both let go more or less for that reason.
One they had a great system in place and the product felt mature, the companies axed them.
The DBA career did seem to nurture some big egos. They had the keys to the castle, a lot of technical sway and could also have a big impact.
They also earnt good money for a while. When I worked for Oracle, there were lots of stories of Oracle consultants being payed day rates which would still be considered high today.
I’ve seen the same ego with network engineers, they setup some switches and configure a couple vlans but act like they’re the fucking shit because they have a cert.
I think this kind of conflict often comes from frustration at developers not having much understanding of the underlying technology that the network engineer / DBA is responsible for.
Networks & DBs present abstractions, but they're very leaky ones, yet developers often expect to just treat them as magical black boxes about which they don't need to know much of the inner workings, constraints, tradeoffs etc. That makes the interface between the network engineer or DBA and software developers a natural site of conflict.
(You even see this above in this very thread, someone complaining that a DBA was punishing developers for "querying the database too much". Most likely the DBA was actually upset about how they were querying the database, not that they were querying it too much, but the developers want it to "just work" so the distinction isn't important to them.)
If you turn up a few times after destroying the gearbox from shifting into reverse on the highway, they might have a word. I don't condone the berating, I just mean to point out the source of the conflict [0]. A car (especially a modern one) abstracts away its insides much better than a database or network does, too.
[0] The mechanic is also being paid by you to fix your screwup, in proportion to the severity of the screwup. Your colleague is not.
Most mechanics I know would grumble a bit after the third time. It's a bear of a job, and they'd make more profit doing twenty oil changes in the same amount of time.
The DBA's job doesn't generally extend to fixing your code to use database features correctly, write SQL in a sane way, etc. Even if it does at your company, unlike the mechanic they're not being paid by you to do that work; they get their salary regardless. So it's natural that if you keep bringing unpleasant work to them because you're bad at your own job, they're going to get upset.
I think a better analogy would be the engineering team we see frantically trying to keep the engines together in Sci-Fi movies/TV. The DBA is on the same ship as everyone else!
I tried to hire a guy for a postgres DBA at a company I had worked at. I knew him from before as a MS SQL DBA from a previous company and hoped he could fulfill the role, he said he could. The guy saved our asses in the previous case.
We gave him like a month paid time to get acquainted with postgres. Dude DISAPPEARS, gets his vpn keys revoked and everything because we're like what the hell. A month later he sends this big long email saying how he got in some altercation with the police, and landed in jail... it was just way too rambling to take seriously. We ask a mutual friend what the hell was up and he said that since he was working too much his wife CONFISCATED HIS CELL PHONE.
I think we called him 'ballgag ***' (fill in the blank with your least favorite person's name) after that
These guys are worth their weight in gold though, I think I heard he ended up getting a job at Microsoft down the line
I had eerily similar experiences from an older DBA guy, who was going through college in his 40's while working away. He knew his stuff, helped a lot optimizing the ETL process, but could turn nasty in an instant, and had a major chip on his shoulder about younger analysts with college degrees.
Only thing, was this guy had zero programming experience outside SQL and Bash. Anytime he had a question in a meeting about some calling Java process, he used to wait until the meeting was finished and then grab five minutes with me privately to ask about whatever. So there was this perceived weakness that his professional persona "knew everything", which meant he couldn't ask fundamental questions or try to (publicly) learn things outside his domain.
In the end, we moved to Amazon Redshift, and he was progressively moved into a smaller and smaller role, where now he just curates 2-year old JIRA tickets. Probably knows he can't get a similarly well-paying gig elsewhere now.
I appreciate your point but it’s important we (being people working in technology) never accept or justify this behaviour. If a job is too stressful, quit. There’s no justification for talented, well-paid technologists to stay in a job that triggers them and harm those around them.
I think we, collectively, should strive for avoiding making other people's life stressful.
Just by having a different role, title or label attached to you can be pretty stressful by itself, specially if you are out numbered and decision making is done by number of hands.
The majority not always get that. Also is so common to be exposed to other people's frustration when explaining things, or denying a request, balancing between letting someone shoot their own feet, explaining once again why that is not a good idea, or just restoring a backup later.
I had a colleague who was a DBA who used to be very loud. In a discussion he'd just be louder than you to shut you up. Really nice guy otherwise, btw, and I learned a lot from him. He was just extremely loud.
We used to joke that he was reading/writing so much all-caps SQL code that his brain altered to scream more :)
This is eerily similar to my experiences with two very, very good DBAs I worked with.
I'm now wondering if there is something about the role that lends itself to such behavior. One day they are super pleasant, helpful and friendly. The next they are chewing people out for seemingly minor and random transgressions and saying things like "ruining my fucking database".
Today these guys remind me a lot of JK Simmons character in "Whiplash"
> I'm now wondering if there is something about the role that lends itself to such behavior. One day they are super pleasant, helpful and friendly. The next they are chewing people out for seemingly minor and random transgressions and saying things like "ruining my fucking database”.
There’s something to your observation. Ok, I’ve held enterprise and application DBA roles, literally decades of experience. Sometimes the cruelty and dominance is necessary because of the responsibility focused on the position. I’ve often proposed being over-accommodating is important for non-architect application DBA roles, whereas the implications of SRE and resource planning might require an enterprise DBA to immediately and summarily cut off stupid/ignorant ideas before they acquire momentum and screw things up for the business. A DBA might not have time to be patient when resource constrained. Also, all too often people ‘suppose’ what the data specialist is doing and gum things up trying to be “helpful” when they should be asking for help, costing much frustration.
I’ve had developers try to take on DBA responsibility and find enlightenment when they learn enough to grok the rationale behind my seemingly arbitrary demands...I try to spend time as a developer periodically so I can refresh my developer perspective and not just expect engineers to automatically conform to my narrow perspective.
Awesome job if you're into data. I personally think data engineering is highly underrated in popularity. I mean not like sitting all day writing ETLs but stuff like building warehouses, ingestion, modeling, etc.
Every job is evolved over time from tools to missions. For example, I was using Visual Basic 6.0 to develop a single-server software on Windows XP about 20 years ago, but now I'm using Golang and many other tools to develop web-based and Serverless services in the Cloud. I'm sure the job description of DBA is being redefined too. As a contributor to https://bytebase.com/, we are hoping to provide a tool to DBAs by offering a web-based collaboration workspace to help DBAs and Developers manage the lifecycle of application database schemas (DDL) and data (DML).
For what it's worth, the FAANG companies generally don't have DBA roles as far as I'm aware. It's generally expected to be part of the software engineering role.
I'm not saying this is correct or better, just saying that's the way it is and it does set a precedent and model for other companies.
Facebook used to keep "Data Engineers" on staff back in 2017 which more or less played a DBA role across their massive data infrastructure. I don't know if that's still the case.
Not necessarily true. FANG has data engineers filling the DBA role. Google also had O ladder folks doing DBA like work in support of Sales Ops, HR, and other (mostly) non-tech organizations.
Anecdotally, I’ve seen less DBA positions advertised over the past 5 to 10 years. I think they disappeared as part of the devops / cloud movement. The lower level aspects of DBA work is handled with cloud managed services (Amazon RDS, etc.). The higher level aspects, DB design, optimization, performance, etc. are done by “regular” senior+ engineers.
It seems like Datadog is defining a new career title called DRE (Database Reliability Engineers), which is IMHO a next-generation of DBA, just like DevOps.
DBAs are a subset of sysadmins, and the sysadmin role is being replaced by devops and offloading more and more functionality to cloud as-a-service products.
Even at large companies, you'll often see databases being run by "data engineering" and SRE teams rather than pure DBA teams. This isn't just a naming difference: the background and mindset expected in these roles is engineering, not system administration.
You're going to be most likely to find traditional DBA roles at companies that run a lot of legacy on-premise software: banks, defense contractors, government jobs, older large tech companies like IBM and HP, etc.
Genuinely curious, how big is the long tail of legacy enterprise software? my understanding is that many "legacy" systems have barebones R&D teams to go along with them. More software has been written in the last 10 years than in the 20 years prior as the field has grown.
Even most FAANG companies are over 20 years old: Apple is over 40. Google, Netflix and Amazon were founded in the 90s. Facebook is the youngest one, founded in 2004, which makes it 18 years old.
Within those companies, there is tons of legacy software and some of it still runs some of their most important systems, despite large sustained investments in modernization.
If FAANG is that way, imagine what it's like at large banks or defense contractors which don't have a strong emphasis on modernization in their internal software engineering cultures.
I know of at least one FAANG retiring the DBA role. While there are huge piles of legacy code, I wouldn't bet on legacy maintenance being a good ticket at a FAANG.
"DevOps" roles are sysadmin roles. The role name changed but the job is identical. I've been doing this for two decades. My title changed but nothing else did. We went from programming Puppet and building packages to programming Terraform and building containers. Actually I end up pointing out bugs to the software developers now because they're worse than developers 20 years ago.
I’m a DBA at a small university. I’ve found that as we move more stuff to “the cloud” on various platforms, my job is much less performance and administration, and much more development. I spend most of my time writing data exchange jobs (between vendor systems) and supporting our reporting/analytics users.
I don’t plan to continue in administration work when I move on from my current role—partly because I’ve found the development to be more fun, and partly because I’m seeing the writing on the wall.
CTO of TiDB here.
TLDR, yes, DBA is still a good job, but to embrace new technologies.
From a database developer's point of view, I have always admired the work of DBA, although I can develop the kernel of the database, I can also write a SQL engine, never been good at writing complex and efficient SQL, totally different skills.
I have noticed a trend in the database field in recent years: Everything goes to the cloud.
Because of cloud is more and more popular, and the cloud is providing fully managed database service, it is hard to say the trend of traditional DBA job is getting less and less, the DBA expert is still extremely popular, However DBA will alive and can be more welcome, because there are more and more new technologies are evolving fast, just like what we're proudly building: TiDB, an HTAP database provides SQL interface, support complex analytic workloads, as well as the OLTP load. DBA could reuse their skills, and even better, they are not just DBA, they can also act as a data expert, help application developers to optimize SQL queries, and schema design, and help them to design and optimize systems.
A good example is my recent little side project: https://ossinsight.io/, although the architecture is simple, it contains some complex SQL in there, I turned to my DBA friends to get this application done correctly and efficiently.
241 comments
[ 3.7 ms ] story [ 249 ms ] threadThe whole "shift-left" movement seems to have swept DBAs along with it. Good to know yer DBs but it might be better to expand your offerings.
Remember that HN is a bubble and world is a much larger place :) No, it is not disappearing "quickly".
Maybe OLTP is moving to SaaS slower, but the on prem data warehouse market must be dying a death?
Anyway, software world is built on DBs, whether they are administered by someone in the cloud or not.
There is noSql solutions being built, but when I left a couple of years ago there were Oracle database backed projects in flight.
Some of the 3rd party applications supported PostGres so they didn't even need to stick with Oracle, but they did. It was when management pushed for a project to be Oracle back that caused a few of us to quit. It's nasty enough to develop on, I don't want to support too.
Things that win always do one of these:
- reduce complexity
- decrease friction
- improve results either qualitatively or quantitatively
SQL is not dead or dying by any means. Its just not the only kid on the block anymore.
The only ways I have seen admin jobs disappearing is that they're renamed to "DevOps Engineer" or a company starts in a magic cloud with no admins and devs doing everything which more often than not turns into a dumpster fire and then they start searching for admins.
You may need less people to manage the cloud but someone certainly has to manage it. Unless someone has a specific responsibility to manage infra or someone personally cares about those things then things go unchecked, ports open to the internet that shouldn't be, no backups, etc., devs are usually concerned with making their app work and not those things.
And this isn't a knock on developers, there's only so much info you can retain and focus on so many things on a day to day basis that there's a need for people to specialize in certain areas.
- the "Dev DBA" who makes sure ER diagrams are constructed sensibly, knows how to look at an explain plan to see where queries are going wrong, maybe even the odd stored proc (heresy!) - the "Sys Admin DBA" who makes sure the database has enough space, rollback segments are big enough etc etc.
That being said, that’s a startup opinion. There are lots of F500s that will want them in their data centers. So like cobol programmers, I don’t think there will be a problem getting employment somewhere in the foreseeable future.
So I hope you find from other people that this is still a good role to pursue and that you do become a dba and work as a specialist with highly skilled teams and make the code world a better place.
For instance we have the EV boom, and visibly a lot of companies are rushing in to try to make as much as they can without planning for what they would do if they become the next Toyota. But surely, some are planning a bit more ahead (or have a more long term viable approach, even if by accident), and time will tell who they are.
My glass half full view would be that we don't need most companies to succeed, as long as the well isn't poisoned.
Now, you don't need any of that. Yet, you can call yourself "full stack". No one truly full stack anymore.
But good lord bootcamps do not produce much in the way of talent in my experience. I'm sure there are some shining stars that benefited, but I have yet to meet one of them. One guy I worked with fully admitted to me in private that he plagiarized his "final" for bootcamp which was a rather difficult algorithm. He just used some open source code he found on github and only slightly modified it. The code he wrote that I had to support was some of the worst spaghetti I've had to pick apart and fix and he was the lead engineer for the company.
These companies would make more money with proper talent. Code camps need to go away.
Bootcamps are like anything: you get out what you put in. They are a(n often effective!) way of learning a skill. If there's a problem, it's with tech hiring and its ability to accurately evaluate candidates. But that's an intrinsically hard task, and I don't know if there's a real solution (and the inaccuracy cuts both ways, and affects everyone, regardless of where they learned to code).
Stop inflating your own narrow experience and projecting it onto a huge swath of people. Pushing stereotypes is harmful.
the anecdote I offered above was not an effort to paint code camp participants as untrustworthy or incompetent. My point is that this individual was lacking in skills and knowledge beyond a Jr level engineer and plagiarized at least part of his codecamp work.
The only thing he needed codecamp for was the "education" on his resume and a shortcut through the interview process. He was made lead engineer, potentially just to boost his resume, but regardless he was involved in "fullstack" development which was leading to some really really nasty issues. He had already worked there for some time once I joined the team, so I have no idea how limited his skills or knowledge were when he joined. What I did see was that he took a codecamp shortcut. This is harder to do with college CS courses and totally pointless if you're doing it for the fun of learning and creating things in the first place (which is the motivation for my and many other people's self-education).
I've worked with self, college and bootcamp educated people. To reiterate I PERSONALLY have not encountered someone from bootcamp who was beyond Jr level. I'm sure there are people out there who are very talented and have used bootcamp education to their benefit, but I see it as an easy system to abuse and I'm skeptical over the actual educational benefits offered by these schools.
I would also like to add that I have worked for a number of companies who refuse to even look at a resume from people with codecamp education (hiring people who are self-educated over codecamp educated even). I think this is a heavy handed approach and disagree with it.
Regardless of the source of education, loading up your company with people who are only Jr to Mid level is a recipe for disaster.
heheh, I hear that all the time, but show me the money...
But they wore lots hats. I worried it was a way to get H1B visas for software dev roles.
So they simply say, “We are not hiring for software developers, we are hiring for DBAs … totally different thing ;).”
I worked for several years at a semi-startup as a Database Engineer where my role was to guide developers in writing performant SQL (and writing indexes for them) and architect their schema to be inline with our future plans and various other database tasks (managing query plans, being an expert on the database feature set etc). I even created an internal course: SQL School, that I included the directors/customer support teams in.
To that specific company my role was priceless, new features could be built in 1/2 the time with an expert writing the queries and handling the database. My programmatic analysis of our 20 year old code base had 5000 unique queries and 3000 more when accounting for dynamic SQL. Not gonna lie it was a complete mess but if I didn't exist they would have needed a lot more database resources. It was a terrible code base and any plan to refactor and avoid this mess would still need my role to do the transition.
I loved that job but its extremely hard to transition to any other roles and nowadays its easier to use alternative solutions.
is this DBA stuff though? Sounds like creating indexes would be basic junior-level backend dev knowledge?
The database was 10gb RDS with no indexes.
and we must note that the business side did eventually bring in external consultants because the project was clearly distressed. So it did eventually get corrected and I naturally tend to see the worse examples of this kind of thing, but yeah, it is possible to assemble a team of 8 developers and get unlucky such that not a single one knows anything about indexes or cloud databases in general.
But that’s turning out to be more and more untrue. Newer engineers really do not know.
Yes, it is or should be.
If you have a mission critical database with a lot of writing to it and the requirement of millisecond response times then every index you implement needs to be balanced against the cost of writing.
Like other database objects, i.e. constraints and triggers that's absolutely a DBA job.
I've worked for a few of those fairly recently. I also worked for a place that was running on a fully custom codebase, no framework, php with all sql scattered through each page and all the devs using their individual machines to ssh into a central dev computer to work (tell people which file you're working on first). No version control of course.
This is an automatic fail for an employer. In interviews I ask, if it comes up I interrupt the discussion, verify, and if they truly develop without valid source control/revision control - I end the interview and inform the recruiter NFW and why.
The lazy stereotyping is inaccurate, caustic, and uncalled-for. I've worked with several bootcampers, and nearly all of them have been entirely capable.
Based on my anecdotes (I guess I am getting into drawing broad conclusions now), good bootcamps are a good way to turn someone into an entry-level engineer who's equipped to start contributing value and then learn more as they go. If they got hired immediately as a lead engineer and weren't ready for it (which they wouldn't be, if the bootcamp was their only experience), that's the company's problem.
I would add too that there's a huge gap in quality between the best and the worst bootcamps; there are some that consistently crank out totally capable junior engineers, but I've read horror stories about others that are outright scams. It's possible we need an accreditation process of some sort.
One Jr Dev won't take down the ship but a whole crew of Jr's with senior titles and authority will at least slow you down to a crawl. In recent years I've worked with teams who are largely made of bootcampers and Jr devs. As I've said from the start, I've been in startup land for a long time now and it's usually all about getting by on a shoestring. I fully understand the financial reasoning behind it, but I dont think the people running these companies have thought far enough ahead and I strongly doubt that any of the places I've worked in recent years will be around even 4 years from now.
Ah hah! Now we're getting to what could be the heart of the issue: short-term business practices, the incentives that drive them, and the market conditions that make it hard to find or afford the necessary technical leadership. This is a complex topic and out of scope, but it feels like a truer source of the problems you've witnessed.
> but from what I've seen, bootcamp alone does a really poor job producing people who know what they're doing... worse so than college because it's meant to be lightening fast education and job placement
It's fair to report that as your experience (even though my experience differs). The issue I took at the top of the thread was with broad, incendiary statements like this:
> small teams trying to support the whole stack with their javascript bootcamp training are the biggest reason so much tech is absolute garbage these days
This is a pile of tropes, capped off with a bold assertion. Bootcamps aren't even especially focused on JavaScript; the ones I'm familiar with also let students pick Python or Ruby for their projects, and also teach the basics of how to use a database and other technologies (of course they don't make you an expert at any of these things). But it was used here because "JavaScript" has become a stand-in in the context of Hacker News comment sections where people are complaining about perceived poor engineering practices. Like "bootcamps", it's come to paint a particular picture in people's heads of a particular kind of dev, whether or not the thing itself is directly relevant to the discussion at hand. Leaning on (and entrenching) these stereotypes is what I'm pushing back against. They aren't accurate, and they encourage certain devs to be disparaged for no good reason.
Our "customer" is the developer or cloud system architect.
I would likely not suggest a "DBA" as a career, but it is a very valuable skill set... To get a job at anywhere but a large business... I feel you need one other hat at least.
I’ve worked at 5 small companies in the last 15 years, and freelanced for a few years. The dev team size was: (15, 5, 5, 4, 8). None of those companies had a DBA. One company we had a full time IT/sysadmin, but otherwise that role was filled by people with a title like “software engineer”.
In truth, I think we often would have benefited from the expertise of a DBA, but we never made the decision to hire someone for that role full time.
I think just in general data engineer is a better term to find the same role across a lot of companies today.
Database administrators keep databases running, managing access and security, doing maintenance tasks, running migrations, etc.
Data engineers are about maximizing the value of existing data by transforming it, aggregating it, etc.
Not necessarily the difference between DBA and DE, just what a flipping DBA even is.
Do you like the work? Do you want to work in large orgs? Keep doing it! If you don’t, there’s plenty of room to branch out and I assure you if you’re half decent at the job your insights will translate well to many other meaningful contributions.
Today I think a "DBA" in a small/middle sized company would be also touching cloud resources and data funneled through analytics and other sources. Basically the "big data" fad we had a while ago becoming just "data", and that data has to be administered, optimized, and backend/frontend devs also need guidance and education on how to best deal with it.
In general, I have the feeling "administrator" roles are disappearing to be either more specific in the biggest orgs, or way broader in the middle sizes/run of the mill orgs.
oh that’s neat. As a data architect, I like to avoid such issues by never letting it happen in the first place. I love Postie but I’m not a specialist. But why not sharding? Seems like a proper data model in 5Tran’s domain would be intrinsically shard-able by client and you could balance it over multiple instances. Does profiling or analyze expose any low-hanging fruit to pluck off for optimization? Or maybe that’s exactly the question you need an experienced Postgres DBA to ask and answer for you...
He got let go for basically having a really bad temper, and we decided not to look for a new DBA. I was sad he was gone but also glad to not be getting screamed at. It feels silly, but I've got really unresolved and mixed feelings about the whole thing. I genuinely really liked the guy, loved talking music and movies with him, but he would heel turn in an instant and just ruin your day.
Honestly wish we had a DBA, I ended up picking up a lot of his responsibilities. I'd love to have someone I could learn from. Basically, I'm getting real sick of optimizing reports.
The impact that you describe very broadly reminds me of https://en.wikipedia.org/wiki/Stockholm_syndrome. I'm still learning about the subject, so the only nearby useful axis point I'm aware of is the concept of chronic trauma, which I'm surprisingly unable to find a synopsis on in Wikipedia (the closest I can find is https://en.wikipedia.org/wiki/Complex_post-traumatic_stress_..., which is vaguely in the ballpark but a couple notches too far).
Personality disorders have the potential to have the same sort of impact as water on a rock over time. I wonder how this person impacted other people at the company - and whether the boundary-defying nature of this sort of problem caused the line between "broken individual" and "DBAs are scary" to be blurred.
It could be very interesting for the various decisionmakers to wind up in a conversation with a good psychologist (psychiatrist?) who might be able to make that line a little bit clearer for everyone (and provide closure) and perhaps even outline ways to screen for this sort of thing happening in the future - which may be the speedbump everyone's (very quietly) stuck at.
The first guy was so irate and literally yelling about his entitlement to punish us for making bad architectural decisions that I thought he was joking. I just laughed, but he got angrier. Then it clicked after maybe five or ten seconds – he was in the process of verbally punishing us for querying the database too much.
The second guy was similar, but didn’t yell. Still super protective of his domain, almost antagonistic about us integrating with the database at all.
Both brilliant, taught me more than I can recount here, hilarious and interesting… But total jerks too, and both let go more or less for that reason.
One they had a great system in place and the product felt mature, the companies axed them.
They also earnt good money for a while. When I worked for Oracle, there were lots of stories of Oracle consultants being payed day rates which would still be considered high today.
Networks & DBs present abstractions, but they're very leaky ones, yet developers often expect to just treat them as magical black boxes about which they don't need to know much of the inner workings, constraints, tradeoffs etc. That makes the interface between the network engineer or DBA and software developers a natural site of conflict.
(You even see this above in this very thread, someone complaining that a DBA was punishing developers for "querying the database too much". Most likely the DBA was actually upset about how they were querying the database, not that they were querying it too much, but the developers want it to "just work" so the distinction isn't important to them.)
[0] The mechanic is also being paid by you to fix your screwup, in proportion to the severity of the screwup. Your colleague is not.
The DBA's job doesn't generally extend to fixing your code to use database features correctly, write SQL in a sane way, etc. Even if it does at your company, unlike the mechanic they're not being paid by you to do that work; they get their salary regardless. So it's natural that if you keep bringing unpleasant work to them because you're bad at your own job, they're going to get upset.
I tried to hire a guy for a postgres DBA at a company I had worked at. I knew him from before as a MS SQL DBA from a previous company and hoped he could fulfill the role, he said he could. The guy saved our asses in the previous case.
We gave him like a month paid time to get acquainted with postgres. Dude DISAPPEARS, gets his vpn keys revoked and everything because we're like what the hell. A month later he sends this big long email saying how he got in some altercation with the police, and landed in jail... it was just way too rambling to take seriously. We ask a mutual friend what the hell was up and he said that since he was working too much his wife CONFISCATED HIS CELL PHONE.
I think we called him 'ballgag ***' (fill in the blank with your least favorite person's name) after that
These guys are worth their weight in gold though, I think I heard he ended up getting a job at Microsoft down the line
Only thing, was this guy had zero programming experience outside SQL and Bash. Anytime he had a question in a meeting about some calling Java process, he used to wait until the meeting was finished and then grab five minutes with me privately to ask about whatever. So there was this perceived weakness that his professional persona "knew everything", which meant he couldn't ask fundamental questions or try to (publicly) learn things outside his domain.
In the end, we moved to Amazon Redshift, and he was progressively moved into a smaller and smaller role, where now he just curates 2-year old JIRA tickets. Probably knows he can't get a similarly well-paying gig elsewhere now.
- DBAs have the most important thing under their management: data
- Any fault they make can result in downtime, data loss, data corruption, etc.
- They typically have to deal with the same (basic) stuff from developers
- I haven't seen any DBA get involved in the data modeling.
- Work on production is usually when the shit hit the fan
- Work on production can be slow (live, large datasets), which makes things more stressful
Just by having a different role, title or label attached to you can be pretty stressful by itself, specially if you are out numbered and decision making is done by number of hands.
The majority not always get that. Also is so common to be exposed to other people's frustration when explaining things, or denying a request, balancing between letting someone shoot their own feet, explaining once again why that is not a good idea, or just restoring a backup later.
We used to joke that he was reading/writing so much all-caps SQL code that his brain altered to scream more :)
I'm now wondering if there is something about the role that lends itself to such behavior. One day they are super pleasant, helpful and friendly. The next they are chewing people out for seemingly minor and random transgressions and saying things like "ruining my fucking database".
Today these guys remind me a lot of JK Simmons character in "Whiplash"
There’s something to your observation. Ok, I’ve held enterprise and application DBA roles, literally decades of experience. Sometimes the cruelty and dominance is necessary because of the responsibility focused on the position. I’ve often proposed being over-accommodating is important for non-architect application DBA roles, whereas the implications of SRE and resource planning might require an enterprise DBA to immediately and summarily cut off stupid/ignorant ideas before they acquire momentum and screw things up for the business. A DBA might not have time to be patient when resource constrained. Also, all too often people ‘suppose’ what the data specialist is doing and gum things up trying to be “helpful” when they should be asking for help, costing much frustration.
I’ve had developers try to take on DBA responsibility and find enlightenment when they learn enough to grok the rationale behind my seemingly arbitrary demands...I try to spend time as a developer periodically so I can refresh my developer perspective and not just expect engineers to automatically conform to my narrow perspective.
I'm not saying this is correct or better, just saying that's the way it is and it does set a precedent and model for other companies.
https://www.quora.com/What-is-the-role-of-a-data-engineer-at...
https://www.datadoghq.com/careers/detail/?gh_jid=1825950
Even at large companies, you'll often see databases being run by "data engineering" and SRE teams rather than pure DBA teams. This isn't just a naming difference: the background and mindset expected in these roles is engineering, not system administration.
You're going to be most likely to find traditional DBA roles at companies that run a lot of legacy on-premise software: banks, defense contractors, government jobs, older large tech companies like IBM and HP, etc.
Within those companies, there is tons of legacy software and some of it still runs some of their most important systems, despite large sustained investments in modernization.
If FAANG is that way, imagine what it's like at large banks or defense contractors which don't have a strong emphasis on modernization in their internal software engineering cultures.
I don’t plan to continue in administration work when I move on from my current role—partly because I’ve found the development to be more fun, and partly because I’m seeing the writing on the wall.
From a database developer's point of view, I have always admired the work of DBA, although I can develop the kernel of the database, I can also write a SQL engine, never been good at writing complex and efficient SQL, totally different skills.
I have noticed a trend in the database field in recent years: Everything goes to the cloud.
Because of cloud is more and more popular, and the cloud is providing fully managed database service, it is hard to say the trend of traditional DBA job is getting less and less, the DBA expert is still extremely popular, However DBA will alive and can be more welcome, because there are more and more new technologies are evolving fast, just like what we're proudly building: TiDB, an HTAP database provides SQL interface, support complex analytic workloads, as well as the OLTP load. DBA could reuse their skills, and even better, they are not just DBA, they can also act as a data expert, help application developers to optimize SQL queries, and schema design, and help them to design and optimize systems.
A good example is my recent little side project: https://ossinsight.io/, although the architecture is simple, it contains some complex SQL in there, I turned to my DBA friends to get this application done correctly and efficiently.