4 ms·
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 th
by Delphiza 4y ago
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.
- DeathArrow 4y ago>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?
- Delphiza 4y agoData 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