I am an aspiring DBA (I'd say in ~3 years I would be ready to apply for a job) and I currently am a programmer. I relayed my future goals to a friend of mine who is part of an Agile SCRUM team in a very heavy and fast-paced software development company. (SDLC to the core).

He expressed his concerns for my career path goals - stating that DBAs for most software dev companies is a dying position due to the increase and development of ORM in the last ~ 5 - 7 years. He said that the company trusts the programmers and most of them are capable of doing most of the work DBAs do. (Stored procedures, encryption, SQL, backups, ddl, profiling, etc.)

Can anyone shed light on their experiences or if they have the same concerns/beliefs with the DBA position?

I am referring to NHibernate and those kinds of systems.

To stay aligned with the Q&A formatting of this site - What are problems that will be faced in the future if everything is converted to and uses ORM and DBA positions are no longer weighing in with the same importance they have been the past decade or two?

I will be honest and admit, aside from basic research I have no first hand experience with ORM. I know this site is supposed to be used for professionals, which is why I feel those who know exponentially more about this circumstance would be able to better identify concerns/problems.

  • 9
    Your friend's concern is about as valid as saying that knowing C or assembly is useless because we have all these fancy high-level languages. There's still people writing assembly code out there today. ORMs don't solve DBA problems (some introduce quite a few), they attempt to solve dev problems. Also having one group that does the full stack (dev down to things like backups) without specialization has scaling issues. – Mat Mar 3 '14 at 7:33
  • Your friend indicates that DBAs aren't needed due to the uptake of ORMs, but then goes on to indicate that the programmers need to spend their time dealing with stored procedures and database profiling. There's going to be a threshold at which it's more pragmatic to have one or more experts than a dozen programmers trying to become part-time DBAs. – Nathan Jolly Mar 3 '14 at 14:28

That is how it tends to work in small companies, but that is how it always used to work for small companies: at a small scale an expert database person was often seen as a grandiose expense when all the devs can do the basics. This is not really a factor of ORMs and noSQL becoming popular recently.

ORMs still have datastores behind them that someone needs to understand and be able to monitor, backup, repair, analyse, scale & optimise and as companies and/or projects grow it still pays to have a specialist in that area. Trusting devs with no data handling specialism is often fine on a small scale, but can lead to significant problems when scaling up. It is quite common to see people gush about an ORM or noSQL solution and claim it means they don't need to worry about the database, only to complain bitterly later when something they tested on a few thousand records falls to the floor when asked to deal with tens of thousands or millions or more (or sometimes even "a few thousand plus one" for really bad designs) and they have quickly got to the point where throwing more hardware at the problem is no use. You'll often find massively complicated caching layers getting created which would not be required if a little more thought had gone into either the initial design of the data store (or a later refactor) - those layers need development and maintenance too so those projects are often not saving money long term by not having a "data guy". In fact if you can keep a foot in both camps (dev and data) then there is much interesting work (and good money) in certain "architect" roles: people either designing the model for projects or earning their bread from taking overly complicated & inefficient monstrosities and helping the dev teams turn them into relatively sleek & scalable creations.

Also don't constrain yourself to being a DBA for a dev team: all of our clients (banking types, councils, a small airline or two) have an infrastructure department in part populated by DBAs who are responsible for making sure their data is appropriately handled. They challenge us (and other suppliers) to ensure we are following good practise, they are responsible for wider issues such as integration of data from systems from desperate suppliers, and they are of course responsible for maintaining in-house databases (mirrors, backups, monitoring, ...) - so there are other places a DBA optimised skill-set is required.

Of course you must stay up-to-date with the newer tools, that goes without saying, but while the job overall has evolved a bit over the last decade it hasn't changed nearly as much as some would have you believe (nor I expect will it in the near future, though keep your ear to the ground for new developments to stay current and avoid obsolescence if I'm wrong about that).

  • To expand on your statement, how do you stay up-to-date? Documentation on a website? Training classes? With ORM sneaking it's way into dev teams/companies it seems as though the DBA career path is an evolving one. – Mark LaREZZA Mar 3 '14 at 14:15
  • Oh it is definitely evolving, as all jobs do over time. Keeping up-to-date is not something I've done as good a job of as I'd like (I have limited time so can't know everything). General tips: watch what people talk about here & other good forums and keep an eye on tech news aggregators like HN. You don't need to be an expert in everything but try to have a play with new tech so you have a feel for what it can/can't do better than what you already know. If you decide you need more detailed know-how on something then use courses & books, and/or try new tools/techniques in personal projects. – David Spillett Mar 4 '14 at 14:06

Not the answer you're looking for? Browse other questions tagged or ask your own question.