Ask HN: Is DBA still a good job?
Is database administrator(DBA) as a career fading out in the IT industry?
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.
Some Microsoft enterprise products were like this (e.g. Dynamics AX) - try understanding 5000 odd tables without any foreign keys!
Surely that defeats the whole relational database concept?
Without FKs you have no clearly defined relations.
Is the idea that you have no constraints imposed by FKs, but tables still have some sort of informal relation?
A bit of a pain when you are looking at the SQL database trying to understand how it is structured so you can extract data in a meaningful way.
Are there resources (e.g., books) that one can get ideas about good data modelling?
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 :)
Discussed by Hillel Wayne at https://buttondown.email/hillelwayne/archive/why-you-should-..., HN discussion at https://news.ycombinator.com/item?id=30251747.
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.
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.
This describes all aspects of software development.
Not using foreign key constraints is a good idea. Occasionally. Very occasionally.
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.
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.
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.
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.
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.
The bugs and poor performance lingers though.
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!
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.
These days you get devops people or data engineers.
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.
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.
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 :)
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.
100%. Data modeling and SQL has become a lost art.
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.
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.
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.
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 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.
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.
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.
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.
What do you mean by this? Any references I could read?
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.
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.
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.
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.
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.
What's that career name? What would be a path towards that career?
(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
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 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.
Drop me a line: vignesh@ or reply here.
And the first line is: Experience as a professional programmer with operational ownership of the software you’ve written.
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!)
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.
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.
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.
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!
* Developer Relations Engineer: https://jobs.lever.co/ottertune/486e1fdb-ceb6-44d4-872f-c66e...
This is a super important position to us, so you can email me directly if you want to discuss: pavlo@ottertune.com
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.
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.
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!
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.
No. Try querying 100 million+ records without good indexes even when it fits in ram. Any kind of query volume will get expensive fast.
Our "customer" is the developer or cloud system architect.
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.
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.
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.
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.
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.)
The 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.
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...
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.
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.
- How do you define good job?
- 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.
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.
It's silly, yes. But this is a silly industry.
I’m looking for a DBA - MariaDB (galera cluster) and TiDB.
Contact info on my profile.
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...
Olso there isn't a need for DBA if you are using other storage strategies.
But in many, many cases there is going to be a large OLAP or even OLTP DB out there, in dire need for someone to love her and take care of her.
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.
DB is a huge system right now, a functional ones has multiple subsystems, possibly handled by different teams.
Can't really see what a traditional DBA fits into this.
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
Databases are such an important part of modern systems it makes sense to have an expert on them on board. I think that would pay off many time over.
However, I'm in a small team and I think it's important that everyone can also help out with a little bit of everything depending on what's going on.
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.
Probably not.