I was a developer and turned into a DBA by necessity. When I was still just a dev, I couldn't get the support I needed from the DBAs, so now I try to be the person I needed help from before.
But, I now understand the problem. At my organisation we have only 2 DBAs, and we can't give all of our time to this task.
To be a DBA is an endless battle against the entropy some devs try to create. The data model should really always be validated by someone with more knowledge and experience. Also, some young devs come up with crazy ideas (for instance, we should not use foreign keys). Others want to load insane amounts of data to process in the database, instead of preprocessing, or using a staging database. There is a continuous stream of bad ideas being implemented.
And when a bad idea gets implemented, it is really hard to undo it and it tends to just create more chaos: you need materialised views to get around bad modelling, or weird views to compensate for duplicate data, etc.
So, yes, a DBA is a really important role. With regards to it being a good job, it depends if your company takes it seriously and puts you in the development process, otherwise you'll be in for a lot of stress.
When I was a younger developer, knowledge of SQL and how your database processed data was an expectation of everyone around me in the field.
The older I get and end up around younger developers, I find that this has become a rare superpower. These days, if I’m consulting on a problem for somebody I can almost assume that it’s a database problem. Either needs to be tuned, indexes are missing, data has been corrupted or duplicated due to lack of constraints, excessive single writes or any number of other issues.
I never thought something that was always a required skill set to suddenly become rare and shocking.
If it makes you feel better, my company employs a lot of engineers (not developers, more like electrical and mechanical engineers). We all do tons of analysis with our gargantuan database and write lots and lots of SQL. It too amazes us when we deal with other departments that are mostly Excel + Python + APIs. They write a lot of unecessary code where a separation between generic programming language and database would make things a lot more efficient IMO.
I will defend that a little. We are all, to an extent, victims of circumstances. All those Excel+Python+API hacks are result of individuals having to deliver results, but with limited tools at their disposal.
> Also, some young devs come up with crazy ideas (for instance, we should not use foreign keys).
My favorite was "we shouldn't use indexes it slows down the DB" by a junior in regards to us collectively telling him to add indexes to a MondoDB collection. When we told him to research it, we meant how to do it.
One of our MySQL instances somehow ended up with two copies of the same index, and any query that tried to use them ended up being a lot slower than it should have been. Dropping the copy restored it to normal speed.
At least in postgres, you don’t need to provide a name, in which case it seems to do no dedup check on the create index. Quite annoying if you’re doing changes ad-hoc
Now, there are I feel couple of different approaches: There's data modelling from a data scientist perspective, which I have limited perspective of. But there's the meat & potatoes of data modelling from regular development / database administration perspective, and honestly any course, book or video worth its salt will start with that. Pick up any well reviewed database administration primer. You can choose any level of detail or depth. One way to get there is look at textbooks from university intro courses. I would use entity relationship or 3rd degree normalization as key words to check what depth it goes into, but I'm old and cranky so take that with a grain of salt :)
Any database primer e.g. intro-level textbook would do, for the basics of relational integrity. But try finding a developer these days who has read a book or shows any interest whatsoever in writing SQL. Most of them just want to work with it behind an abstraction layer.
>There is a continuous stream of bad ideas being implemented. And when a bad idea gets implemented, it is really hard to undo it and it tends to just create more chaos.
This describes all aspects of software development.
Textbooks advocate a split between DA data admin vs DBA database admin. The first manages the model, the second manages the tech. You sound like nobody is doing the DA role, so all misery drops on the DBA head.
Thank you for being the DBA that helps devs. I found myself similarly frustrated when I was a developer. Now I work in DevOps, and I still cannot get traditional DBAs to deliver. :(
All database designs have foreign keys whether they are enforced in the database or not. If they are not obvious from the documentation, that is a documentation problem.
Tangential, but this is one of the main reasons I never liked Ruby on Rails with Active Record when I first took a look at it.
Not having DB-level foreign keys by default always drove me insane. Isn't maintaining data integrity/correctness half the point of using a SQL database lol?
Foreign keys as a concept are a critical portion of a data model, but may reasonably choose to not enable them via schema constraints due to write performance, scaling, sharding, or replication issues.
If you have a super high write throughput table (say a constant stream of sensor data) foreign keys and extra indexes can slow it down to too much. Besides that, you should always use foreign keys.
A lot of answers here entertain the idea that DBA role are disappearing...
I would argue that it's way more accurate to say this role is actually outsourced in most organizations with all the tradeoffs that come with that strategy. I begged my former employer to subscribe to a good PostgreSQL support company. Guess what the one we picked is constantly looking to hire new DBA to sustain growth...
I was in database engineering/administration position for the last 10 year on a small company. It was exhausting because management wouldn't care to rely one guy to manage the whole data stack. It was rewarding because the CEO saw me as probably smarter than I was because I knew SQL well enough to produce outstanding value as a single individual.
Often reading HackerNews I felt like an imposter because NoSQL was the new hype and database was seen as a thing of the past... well trends reverse... and people will always need reliable systems to handle business critical data.
So maybe in a few year after few major Cloud data horror story DBA will become the new trend. No one know.
But learning how to handle data? That will always be handy no matter the underlying technology.
> this role is actually outsourced in most organizations
Or in-sourced to developers. In places I've worked it was a developer's responsibility to ensure that a DB is used properly. None of them knew the DB good enough (they need to write code and have no time to read DB docs) so the result was mixed at best.
This is my experience as well, I spent a few years complaining that my colleagues didn't know their database well enough, and it was causing unnecessary bugs and poor performance.
I wanted the company to pay for some basic courses on the databases we were using, especially for the more junior Devs.
Instead we switched database like 11 times and now I don't know the database either.
Same at my previous role - we did have some people who were really good at some point, and into DBs. We had a very solid Redis and PostgreSQL set-up, and some advanced stuff for simple data in Redis - but once that knowledge fades with attrition, making space for continued personal development into how two very different DBMS work for a small team is not easy, and it just stays untouched, disliked, and somewhat abandoned forever more.
Particularly in places with dedicated DevOps people.
It is common for DBA work to be split between infrastructure and dev teams, without a dedicated DBA though perhaps with one or more particular devs acting as a local database “expert”. In a well run organisation those teams will communicate well, how often this works so smoothly in practise I'll leave as an exercise for the reader to investigate!
Yeah, everybody thinks that their cloud database dujour has them covered. Then by accident they learn that it was not automatically "highly available" and that they need to restore from backup...yesterday's backup...and yes, the laws of physics still apply (the database doesn't index itself).
There are a staggering amount of configurations resulting in a number of states, most of which are not desirable for anything beyond the dev environment.
Senior devs think you're a fucking wizard if you understand 20% of it. Scary.
I'd say the role is morphing. Organizations need employees who would be able to ensure consistent practices, automation, compliance on top of cloud solutions. At some point of scaling the team, having a few DB experts will increase efficiencies and ensure that practices are automated, documented, and taught to engineers compared to letting engineers discover these on their own.
Next, the DB experts help improve efficiency. It's too easy for engineers to over-provision a DB instead of rewriting the query or adding an index or two. Lastly, engineers flock to new datastores on the Cloud that may not be the best fit for the use cases at hand. So advising teams on which datastore to pick is another angle of the role.
> Next, the DB experts help improve efficiency. It's too easy for engineers to over-provision a DB instead of rewriting the query or adding an index or two. Lastly, engineers flock to new datastores on the Cloud that may not be the best fit for the use cases at hand. So advising teams on which datastore to pick is another angle of the role.
Moreover, involving this group of people in design processes will keep you from creating wildly expensive and unnecessary systems. I can't tell you how many times I've seen projects start using wildly expensive Neo4j and a bunch of cutting edge research/non-production dbs (and all of the associated operations work to productionize and software written to utilize) all to end up getting migrated back into Postgres once performance barriers get hit somewhere and engineers realize that Postgres can handle the use case just fine.
On a big database migration a few years ago where I was working, the “solution” was to assign one of the engineers the DBA-ish role for the duration of the project. Turned out to be a bad idea, but he did his best.
If we had had anyone who was actually good at that stuff, besides the few top people who were needed elsewhere, that person would have emerged a hero.
DBA is one of those roles that needs a few years to come back into fashion. Once people realise how incredibly terrible the "new" paradigm is, it will come back in vogue.
It will be while before people pay 100k+ to hire somebody to administering something that you can get from any PAAS in a form where it does not need that. Even if you self host, this is not a thing anymore.
These days you get devops people or data engineers.
I'm not sure if "disappearing" is the right word, but it is definitely moving towards also requiring reliability engineering / stronger than usual automation skills.
It's also a role that's thinning out, because these managed offers are good enough a lot of the time and developers are using the most common parts of the feature set on offer.
I've read a take on NoSQL that it's aimed at web developers who don't want to understand or work with a proper database. I find that in a lot of businesses, the core data is still a regular database, with NoSQL databases only used for non-critical data; it ties in to CQRS as well, with writes being done to a central database, and a read-only cache like redis being used to provide data for the client-facing applications.
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.
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. ;-)
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
DBA is still a necessary job. I would say more and more so: Over my own now 25 year career in IT, the average developer seems to have less interest/knowledge in data modelling and administration. I don't think you'll find great DBA skills let alone a dedicated role in a small high velocity exciting startup - I feel they'll cloud brute force their way :). But in a large organization, a good DBA is vital. I have 2-3 on my project team and always looking for more.
It is astonishing how much a poorly tuned data request / SQL, or poorly designed data model / table, can impact performance by multiple orders of magnitude. It is also fascinating how much addition of specific index or tuning statistics can help execution. There comes a scale where throwing more hardware on performance problem is prohibitive over hiring a good DBA, as much as current thinking is that "hardware is cheap". But on a regular basis I'm seeing experienced, serious, dedicated developers create SQL that is functional correct and reads 10 billion rows into buffer in order to spit out a single row answer (sometimes of course that's necessary, but usually not :)
> Over my own now 25 year career in IT, the average developer seems to have less interest/knowledge in data modelling and administration.
Even when it's clear as day that the data model is incorrect they often just ignore it. They blame MySQL for not scaling while having ten joins per query and using ORs like they're going out of fashion. Say it can't be done in another way, even tho clearly it could.
Or say how the benchmarks for Elasticsearch are specicially crafted, you can say that when you get 30k per second and they get 50k, but when you get 50 per second and they get 50k per second it's not their benchmark that is specially crafted it's your data model is crap.
I honestly think the thing that costs most companies the most in their hosting is developers not using databases correctly and spiking the hosting costs. I literally saw one company have to spend 20,000 a month for 500 requests per second on elasticsearch.
Ten joins per query is quite nothing. I tend to see the opposite problem, where new devs denormalize a bunch of tables thinking it is going to improve performance when it fact it duplicates data everywhere in tables and indexes and makes things much less cache efficient, the CPU spending much more time stalled (https://en.wikipedia.org/wiki/CPU_cache#CPU_stalls) moving different copies of the same data in and out of ram and caches (or god forbid disk).
JOINS are a performance _enhancement_ in an efficient, indexed schema, especially with narrow tables when the joined pages are small enough to stick in caches longer.
This is why columnar stores like elasticsearch effectively only allow single column tables so every column always has to be joined. They also aggressively compress pages of these columns to make them more cache efficient. Its much faster for the cpu to compress/decompress/join on the fly than to move uncompressed denormalized data from different levels of cache.
In SQL world, if you keep your tables narrow and normalized and you get the same benefits plus the benefits of only having the indexes you need (also more cache efficient) rather than index everything and throw hardware at it like elastic. With SQL, you also avoid the issue of sending data over potentially congested and less reliable networks that distributed DBs like elastic have.
> JOINS are a performance _enhancement_ in an efficient, indexed schema, especially with narrow tables when the joined pages are small enough to stick in caches longer.
When used correctly nearly everything is good. But in reality most production applications in the world you'll find them doing joins where it's not performant. You'll find 1 to 1 relationships all over the place.
In many scenarios the application and database would run quicker if you do 11 queries instead of doing 1 query and doing joins to fetch the other data. In many real world scenarios. And you can literally demostrate that to some developers with a pull request that performs better and they'll continue to write their crappy SQL.
Knowing how to data model is a skill I learned and got good at long before I was ever forced to write my first SQL statement. For all it’s power an usefulness SQL is to databases what JavaScript is to web development… some people are WAY too obsessed with using it for everything they can. And this is a bad thing. I find “DBA”s tend to reach for SQL first and can cause their own kind of chaos. From writing difficult to test code because they hand wrote SQL that only works on the production database (PostgreSQL vs in memory SQLite) to my pet peeve of constantly suggesting that a problem would be trivial to solve with stores procedures which would massively complicate (requirements completely replacing) the database migration system currently in use (because most frameworks, like Rails, Laravel and Django don’t have good built in tools for managing, versioning and updating stored procedures).
Adding a DBA to a team is like adding an opinionated senior developer, sometimes you need that experience and sometimes it’s just going to be a total fucking pain in your ass.
If you feel you need better data modelling skills in your developers, don’t hire a DBA, hire developers that know how to do data modelling.
This is a good caveat, and I agree with the thrust of your point. Especially about stored procedures. Sometimes DBAs, especially corporate oldschool ones, can really propose DBA-only solutions, and it's painful.
I think another way of thinking about this is hire "former DBAs."
Most of the developers I know who had really solid SQL, the greybeards I learned from, were either former DBAs or former sysadmins who had become full-stack developers.
edit: Another was a junior developer who interned two years as a DBA role. He was desperate to lose the DBA title, and I always respected that, but damn if his SQL wasn't better than mine.
Agreed; depends hugely on system and project/team.
I'm in the ERP space (Fun!:), which means a lot of code is effectively legacy and a lot of standards/methods are also effectively... old :-).
We are lucky on my current project to have developers who ARE senior and experienced and pretty good at data modelling; but there is still a lot of need for somebody to own the back end system and design maintenance and notice problems and optimize things holistically as opposed to program by program.
So I guess I should've clarified - a good developer certainly helps but does not obviate the need for DBA in many scenarios.
I would argue that a developer that can't structure and query data for efficiency and integrity, is probably wreaking havoc in the rest of the systems too. You don't need a DBA, you need a better developer. Managing state is an important skill outside of DBs too.
I'm ~7 years into my professional software career and it wasn't until the last year or two I took a huge interest in the database layer, I can attribute a lot of it to Designing Data Intensive Applications.
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.
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 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 :)
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 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.
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.
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.
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.
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 important to understand why it existed in the first place. A long time ago, if you were building business software on a database at all, it was a very costly commercial database. Imagine 6 figures a year for the software licenses, the same amount again for a support contract, and a similar amount for the hardware to run it on. If a company is spending $1M+ a year on a critical piece of software infrastructure, that is very complicated in addition to being very expensive, they will usually be very open to spending more on top of that in salary to employ experts to look after it. Those experts are your DBAs.
A funny thing happened when MySQL and Postgres made databases "free": companies (irrationally, IMHO) stopped being willing to pay for experts to run their database software. That duty became a secondary responsibility of developers or operators or both, none of whom really wanted to do it or cared to learn how to do it well. There are counterexamples, sure. Some companies get big enough, and lean on their databases hard enough, that they cultivate true competence in them, but it's rare.
And then along comes AWS RDS (and similar), automating away the most tangible aspects of what DBAs did: HA, backup/restore, configuration, provisioning. There's still plenty left for DBAs to do, but it's stuff people don't understand the value of. As above, the residual DBA duties silently fall to developers and operators.
Also, being able to run databases for $0 in licensing on small-ish, commodity servers has led us to use more and more of them, rather than giant, central, shared databases. This amplifies all of the above effects. It also has important 2nd-order effects on the social organization of our software-building endeavors. When databases were shared by many apps, it made sense to think of them as their own services. When each database is built and run to service exactly one app, that makes less sense, plus it's also easier to push everything onto the devs (as above).
Make no mistake, all these companies still need DBAs. Their schema designs are awful, their query performance is worse, who knows if their backups work, etc etc etc. But we don't see it, because there are so few people working in software today that understand what a DBA is, or ever met (and worked with) a good one.
It's rewarding work if you can get it. I still love doing it. But outside of the Oracle and Microsoft ecosystems, it's not really a career.
> When databases were shared by many apps, it made sense to think of them as their own services. When each database is built and run to service exactly one app, that makes less sense, plus it's also easier to push everything onto the devs (as above).
I think this is a really good point. The move towards microservices architectures means smaller and smaller databases. But more importantly, the data is distributed, so a lot of query complexity moves to services and the data is effectively modelled in a nosql style.
I wonder if newsql databases will bring back the database-as-service paradigm. At some point the costs of running hundreds of tiny databases is going to catch up to companies and the prospect of having a single critical instance to care and worry about is going to look attractive. Maybe we will see the return of the DBA in a new avatar over here.
You can probably search around for references on distributed data management. But basically, when your data is split across different instances, you can no longer do joins or transactions or rely on the database for acid guarantees. All these things must instead be handled in code which is exactly how you would work with data using a nosql database as well.
Varies by actual DB but: with this architecture, if the DBs are NoSQL then you didn't lose as much by splitting up the databases, but if they were SQL then among other things you lose transactions across those DBs (or now need costly distributed transactions), effectively making the collective SQL system behave more like a NoSQL DB.
HA is not automated. I know plenty of people who think it is though. None of their shit is highly available. It's easy to handwave and assume it's working automatically though, given all the other hype ignorance. Ask a dev to test the RDS HA. Protip: Take a backup first.
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.
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.
> 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.
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.
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.
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.
> 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'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 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.
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.
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 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.
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.
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.
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.
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.
Yes. Lots of companies employ them. They tend to be less flashy companies than the kind you see talked about on here. Think banks, insurance companies, manufacturing companies, etc. Not startups / pure tech companies - while they may have them, you're more likely to encounter them mashed together with other roles (data engineer, devops, etc...) in the tech companies that tend to chase the latest dev tool fads.
Personally, I'd take a proper DBA over modern data engineers any day - there's a ton of value in knowing how to set up, maintain and use an effective SQL database. It's just not a place you find shiny new tech, so people regard it as boring and old. I'm biased though - the beginning of my career I was a DBA in a boring industry, but it taught me A TON that still has an impact on my skill set 30 years later even though I'm now working in totally different areas.
Like everything, for legacy software (of which there is a lot in the enterprise) DBAs are still needed.
I haven't seen as many DBAs in the last 15 years. In that time, two things have happened:
1. Servers have become faster (obviously). I spent a lot of time in the late 90s and early 2000s optimising databases, from the data model and query plans to physical hardware. We forget how slow hard drives were, and how challenging a database cluster is to run on 4GB of RAM. These days we don't spend much time worrying about database scalability for most cases. There was a time where many businesses were pushing the upper limits of database server performance for hardware available at the time.
2. SQL databases have become less central to the solution. Everything used to be modelled in third normal form and the SQL database was the 'single version of the truth'. Now we may put some data in SQL, some in a document database, and some on a queue to be saved in a datalake.
If you are asking specifically about SQL DBAs then yes, the career is fading. However, as others on this thread have pointed out, there is always a career for people who love data, and know how to work with it.
Data Engineering. The exact job varies a lot. It can be part of a data science team, doing interesting stuff. It can also be a version of plain 'ol ETL - enterprises increasingly need to take data from one system and move it into another for reporting - which may be better suited to consulting/contracting gigs. Be careful with Data Engineering, it is also one of the first jobs that is outsourced, so use it as a pathway (you get really good business understanding when moving data around).
(Microservices) Data Architecture. Deciding where data goes (SQL, NoSQL, data lake). The microservices trend is flippant about storage and sharing of data, so being able to architect data stores is crucial. This may be a good path for full-stack developers that like data - come up with better solutions and take that knowledge to other teams. Small dev teams put in PostgreSQL and seldom consider queues, time-series databases, search services, and other places to put data.
Data Governance. The interception between crud data, data engineering, and security. There is an increasing need to know where data is, who has accessed it, what it is used for. You'll get good visibility at the exec level and related career prospects if you ask awkward security, compliance, ownership related questions about data - and find answers and solutions to them
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 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.
> I never came across a DBA which has more than scripting experience.
The job title is not “database administrator”, it’s “systems engineer - database”. Frankly if it’s remote I would apply for it, even though I’m not a Postie specialist. Looks like fun work. Hopefully not too much corporate bs. I ran away from a job offer at Iridium because they had too much corporate overhead and management fad baggage to contend with, coupled with pointless face time at the office (no other team member at the location!)
It is available remote. Not only in the US. Also in Canada, UK, France, Germany, Singapore, Portugal. If you have a resume forward to vignesh@cloudflare.com
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.
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.
DBAs are done. A certain level of database proficiency is demanded of all the other engineers and non-engineers. And if you are really working on a super-awesomely-complex system that needs super awesome scaling, then..... you make shitty queries anyway and just increase the size of the memory cache or the number of database server instances. What!??? Heresy! Well okay then, go find a bad query and improve it so you get a nice bonus later. See, look, still no DBA on staff.
Major products are released and operating right now with incredibly low performant queries and uses of databases. The infrastructure people and services keep the databases running.
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.
"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.
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.
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.
This topic inspired my co-founder and I to build dbsupervisor.com as a tool to monitor database health, and offer opinionated suggestions to improve product uptime and performance.
As others have pointed out, traditional DBA roles are fading away due to cloud offerings abstracting many of the problems DBA’s would otherwise be responsible for. Hardware is cheaper and more available which means that companies throw more RAM/CPU at their problems, whilst areas like index planning, performance tuning, query optimisation, and resource monitoring take a back seat. In our experience, this eventually catches up to you in the form of poor performance and unhappy customers.
We believe that tech can augment most of the insights offered by a traditional DBA and help avoid these pains early on, especially for smaller teams with limited database expertise. We’re currently in private beta, but will be opening up more broadly in the coming weeks. We’d love to get your feedback on our approach - sign up for the beta or AMA if you have any questions!
Recently I’ve thought it might be good to go back into consulting as a Data Architect. I would happily partner up with a good product if it there was (hands waving) “synergy”...
If you are a disillusioned PostgreSQL or MySQL DBA and are looking for a way out, then we have a job for you! OtterTune (https://ottertune.com) is looking for a plucky individual that wants to help us spread the message on how to use ML to automatically manage and configure databases.
I was a database consultant for many years, there used to be lots of DBA work, there's a lot less now - the hardware is faster, memory is cheaper, disks are SSD, so a lot of the hard parts of the job are less hard now, also databases are self tuning now (to varying extents). It used to be you'd need a specialist to just keep any application running, now it doesn't matter much. The only hard area left is large data warehouses, and there are few of those and the interesting part is the data engineering role not so much the admin part. The DBA role for these is pretty standard now. Also a lot of apps are moving to the cloud, so less work there as well.
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).
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.
No. Because database will still be the core of the IT service, enterprises still need engineers have the expertise about database. But I think the responsibility of DBA is changing, due to evolution of the database technology and the movement to public cloud service. Since the third-party vendor will provide better and better database service (I would like to use service than product, because the rise of DBaaS on cloud), DBAs could shift some of their time from DB layer to the platform/application layer. Maybe there will be a new name for DBA, like DB/Data engineer.
It's still a well-paying job, and still necessary anywhere there's a complicated database and a lot of money riding on it working as expected. But most older DBAs haven't learned any new technology or even database technology from 10 years ago... many don't even know how migrations work. Being a DBA that actually understands software development would make you a keen asset at any shop depending on large-scale SQL databases (which is.... most large companies). Distributed databases would also be good to specialize in, but the market is smaller.
Being the person who everyone turns to for database/query issues is a decent niche. If you work with Postgres it's pleasant for the most part as well. I don't think the type of places hiring a "DBA" are typically high caliber employers, it tends to be a lot of enterprise type stuff, so I'd focus on being a software engineer/architect that just happens to lean heavily on the use of database features to accomplish your job rather than trying to specialize.
> If you work with Postgres it's pleasant for the most part as well.
I’ve schemed and schemed for years and still those Postgres-central jobs elude my grasp. Still dreaming. In my current job I go back and re-cast the solution in Postgres or SQLite in my spare time (typically really easy btw) but management isn’t interested in non-microsoft/non-oracle solutions.
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.
I moved out of DBA work after many years working for large enterprises. Databases had become more of support model. There were very few new databases you were able to contribute to. Either it was an off the shelf package where the database structure, configuration and coding came from the vendor or platform as a service. As a contractor I went where there was more work and more money: security.
There's always work reducing risk...
The answer is not boolean , it depends. Sure there are lot of database migrations that happen to the cloud and fancy NoSQL datastores , but there are always so many data islands , warehouses that hold up data in traditional enterprise databases.
And all the move to cloud is not straight too , there are lift and shifts where the same DB runs on another machine. There are lot of "microservices" that data from these that need housekeeping that will go on anyway.
How about NoSQL DBA's ? We moved a lot of data to a NoSQL datastore (HBASE) and added Phoenix on top of it (SQL flavour). Sure enough there were app queries that did need a relook at! , newer query patterns emerged , secondary indices , data re-indexing , adding more RegionServers , Splitting regions , tuning guideposts, changing the GC parameters for the stop the world GC's was all needed. While a lot of these are taken care in PaaS , not every application runs on CosmosDB , DynamoDB or the like. There is always a niche and it is here to stay!
I would agree that in some organization sizes it is fading out & becoming hidden by ever increasing raw compute/disk performance which inevitably hides many bad queries.
However for some orgs this becomes a brick wall they eventually smash into.
The cloud vendors now provide moderately ok database offerings on a variety of virtual hardware that allows you hide a lot sub optimal data modelling, index usage and inefficient data modelling.
Any database workload is performant while all the data fits in ram.
I agree with some other comments that there is a bit of a shift left approach to the DBA role now. I find that dedicated DBA skill sets are somewhat useful up until a point then they struggle to have context of the application stack beyond.
If you want a solid DBA career you may want to look at a SRE track/pathway that includes some deep focus on databases.
You will want to know the how various index types work, when and why to use them.
Data types.
Intricacies of various database mechanics that impact performance and scaling workloads.
Solid foundations in highly available system design, maintenance and operation.
A willingness to be on-call.
A willingness to write code to a software engineer level or send in changes to the dev team/s to help optimise queries, drivers, connection pool settings/timeouts or ORM usage (shudder).
I think the days of a pure DBA role are coming to a close in technology lead organisations. Maybe not in banking/insurance or other orgs where DBAs found a home to sit in the back office doing minute query tuning on a reporting query etc.
If more developers have read and understood the content in https://use-the-index-luke.com/ then there would be less need for DBAs.
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.
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 believe new technologies will continuously injest energy to the DBA staff, and change the way of how DBAs treat database management. Different and further research and developement in database area nowadays, like distributed database, cloud native database, serverless database, ai4db, db4ai, NoSQL, NewSQL, time-series and graph etc, what I mean the industry always need and welcome specicialists and professionals in each area.
In the meanwhile, there will be somewhat new framework that makes DBAs life easier and bring a broader entrance for anyone who want to manage their database well.
DBAs will always exist wherever crufty shit like Oracle, DB2, and Teradata are deployed on-prem. It's fading for sure, but it's a pretty comfy job from what I've seen. You're basically in a silo no one wants to mess or deal with.
I've worked over 20 years as a DBA, mainly Oracle but also with Netezza, Teradata, Postgres, MS SQL Server, DB2, and Mongo. I would say DBAs are still in demand. I recently was laid off from a place that wanted to outsource DBAs and it took next to no time to find my new job. The pay is stellar, imo.
Having said all that, I could see it would be hard to decide right now, as a new IT person, to get into being a DBA. We wear so many hats, and are generally looked to for anything that needs to be done. As others have stated, a lot of companies don't seem to care that their queries are absolute shit, they just throw more hardware at the issue.
1) Maintenance - rebuilding indexes, managing disks
2) Performance - identifying problems, training devs
3) Architecture - helping people change DB architecture at scale
4) Automation - DB-as-code and automatic migrations
Some of these go away or reduce with the cloud but an awful lot of companies don't or can't use the cloud. Even if we theoretically could, we might have a large existing database on a live system that would not be quick to migrate to the cloud (the copy process would take long enough) only to find out later that there is some issue with performance or pricing, so we leave it where it is on-prem.
I'd say "yes and no" from what I could see. If you are looking for a DBA job only in a big/small company, that will be very hard to find. Sadly, most companies will expect you to do DBA work as a "side job" (they see it as an unnecessary expense).
However, if you have expertise in specific databases, start a consulting company. That can be a very lucrative job, and you won't be tied to your employer's mismanagement - I've seen numerous times where a company will hire more managers and fire engineers (or cut the costs in hardware) due to increased costs by those managers. And they end up badly pretty quickly.
I think this advice should go with a word of caution since doing DBA work and running a company are quite different things. If you are a DBA with strong networking and leadership skills it might work though.
Otherwise I would recommend eating the cut that an intermediate will take and let yourself be placed by an agency as a freelancer.
(All assuming the OP is talking about strong pre-existing specialized DBA knowledge, not starting to learn it.)
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.
It depends. I guess if you want to work in a corporate setting like an insurance company, there will be a need the next years.
I would suggest to keep your highly specialized database skill and invest in infrastructure as code methodologies (e.g. terraform) so that you can be the enabler/trainer for other teams on how to setup/upgrade their database instances and also help them with database migrations.
So I would say you can transition to a highly specialized consultant (maybe in house) on how to optimize a database to keep your skill and learn infrastructure as code skills.
I think DBA will finally transform to DA: Data Architect, Data Admin, Data Analyst.
As for Data'Base' Administration, there are going to be more and more tools, SaaS, and PaaS to eliminate thosea dmin work...
Consulting across 12 companies in the software development and delivery over the past 10 years - I haven't worked with - or even come across a single DBA in that time.
There are people working in data analytics / warehousing / "big data" but I don't think that's the same as a traditional DBA role where you're smashing out SQL.
I suspect DBAs are still around in older enterprises or maybe large companies with very complex databases - but I don't think you'd see many in modern software development.
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.
- You assume it was a good job by using still. Why was it ever a good job?
- What is your age?
- How long do you plan to stay in the industry before retiring?
- Are you passionate about it?
- Do you enjoy it?
- What do you want to achieve?
- What pay you expect?
- How much money you need for your lifestyle?
I could go on forever but in order to answer your own question (if it was not asked just to promote your business cloudsql or whatever) your need to answer these first.
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.
DBA skills as such are definitely needed -- more than ever.
But the job title as such is dead as a doornail -- along with "systems administrator", "webmaster", etc. You need to call yourself a "data engineer", "data warehouse architecht" or something similar.
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.
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.
Just call yourself sysops or database engineer depending on if you actually want to maintain DBMS or write sql. Or come up with dbops or sqlops lol. Everyone else is doing it.
Question: How do I get into a traditional DBA job without SQL Server/Oracle/Mainframe DB 2 experience? Looks like the dinosaurs are the only ones offering such positions.
I'm a developer who started a cloud based pos app from the ground up. The last two years of scaling have been a master class in sql and thinking about data.
I blame a lot of performance and scaling problems on ORMS which are fundamentally a bad abstraction for sql and enable devs to brute force something that "works" instead of dinging an elegant and high performance solution to a problem. Most devs don't really understand how to use case statement or aggregate queries for instance. When i was building out analytics pipeline, my original vision was to use some sort of elastic search. We're scrappy and bootstrapping though so instead I came up with a set of triggers that populated special tables that pre-crunch certain bits of data from the original source. Between that and judiculous use of indexing, we are able to do realtime queries with no delay. If you know how to layout your information correctly, the database can be more than fast enough for most use cases.
I think everyone working on database abstraction libraries should look at Ecto. It doesn't try to hide sql. instead it embraces the semantics of sql and extends it to make it more ergonomic. It become easy to escape hatch into raw sql for things the libary doesn't support and even better, I don't have some werid under the hood transformation going on that messes with my intuition for the sql being generated.
tldr: stop treating sql as a glorified k/v store. you can do a lot of cool stuff inside the db and benefit from a crazy speed boost
They come with different skillsets and sadly, some very different competences[1] Ignore the latter point and you'll think of them as equal therefore interchangeable and start outsourcing to save money. Ok, buy cheap pay twice, or more likely, much more.
[1] My replacement at my last job didn't seem to understand MSSQL server even had a query optimiser. His knowledge was 20+ years obsolete at least.
But, I now understand the problem. At my organisation we have only 2 DBAs, and we can't give all of our time to this task.
To be a DBA is an endless battle against the entropy some devs try to create. The data model should really always be validated by someone with more knowledge and experience. Also, some young devs come up with crazy ideas (for instance, we should not use foreign keys). Others want to load insane amounts of data to process in the database, instead of preprocessing, or using a staging database. There is a continuous stream of bad ideas being implemented.
And when a bad idea gets implemented, it is really hard to undo it and it tends to just create more chaos: you need materialised views to get around bad modelling, or weird views to compensate for duplicate data, etc.
So, yes, a DBA is a really important role. With regards to it being a good job, it depends if your company takes it seriously and puts you in the development process, otherwise you'll be in for a lot of stress.