Only person with access to the servers that host the data, the go-to person to create a new database cluster for new features, the person to design new schemas and the only person to contact if there is a problem with the database in a production environment. Since dbas traditionally have unique roles, their time is tight, it becomes more difficult to see the big picture when the day-to-day tasks are overwhelming. It is common to resort to flimsy tools like bash for all sorts of operational tasks in the dba domain. Need a fresh database setup from a clean os install? Take, v Alidate or restore backups? Rotate outdated partitions or data? When your most commonly used tool is the bash script, everything looks like a nail. I'm sure many company mailing list readers are tweeting about how powerful bash is, but please save your comment until idoes this all sound like your job description as a dba? Does the job description talk in detail about upgrading servers, creating and testing backups, and monitoring? Most typical dba job postings will be sure to say that you need to set up and configure "Multiple" database servers (as dbas are expected to craft them by hand) and automate tasks database management with scripts (handmade). Is this really a scalable approach for what is often a one-person team in a growing, Fast-paced organization? I'm here to assert that your job is not to perform and manage backups, create and manage databases, or optimize queries. You'll do all of these things as part of your job, but the primary goal is to make your company's data accessible and scalable. It's not just about the company running the current product, but also creating new features and delivering value to customers. Why you might want to ask, why would I do all this? There is an argument for continuing to perform the traditional dba role: job security, right?