What are the differences between the daily tasks/duties of a Mongo DBA compared to a RDBMS DBA?

For example, some sites claim that a MongoDB DBA would not require to do data modelling or designing the database, as that would be done by a developer or application designer.

This would mean some tasks are no longer needed to be done wrt MongoDB administrations, which was earlier being done by the RDBMS DBAs.

What other tasks would be required, that are not normally in the schedule of a RDBMS DBA?, and also the task which the RDBMS DBAs used to do but is no longer in the schedule of MongoDB DBAs ?

I'm new in MongoDB administration, so I'm trying to identify these task so that I may not commit the mistake of doing things in my daily task that are not needed or I miss something that I need to.

Can any experienced MongoDB DBAs help me out so that I don't do any foolish mistakes in my work ?


2 Answers 2


I have been in the NoSQL field since last 3 years.
Being a MongoDB DBA you need to work closely with Development and Ops teams. Following are the things you need to do as day to day tasks as a MongoDB DBA. The role can be broadly classified into three parts:

  1. Administration:

    • New deployments (manual/automated)
    • Deployment design of your database systems
    • Monitoring
    • Backups & Recovery
    • Security
    • DB Health best practices
  2. Development:

    • You are required to write code/scripts that run periodically/once on your data, this may be required to generate reports & analytics.
    • Debugging application-db issues with development teams
    • Implementing availability, scalability and security from app side
    • Querying database on staging and production whenever required
    • Suggesting indexing strategies and implementing them
    • You are involved in database design and modelling
  3. Performance Tuning:

    • This requires continuously measuring performance of your database using tools
    • Create indexes or shard database based on the requirements
    • Report database performance to the dev team
  • Thanks for the nice answer Astro. Building up what i got in 2 answers from here. Involved is a lot different (for database design and modelling )from doing it alone, also we dont do normalization , backups and testing restores ( have never done this in my day to day job), DR strategy, data tier programing (not sure what this is). Can i conclude that we MongoDB DBAs dont focus on these, alone ?
    – Mechro
    May 15, 2016 at 2:50
  • "data tier programing" -> stored procedures, triggers, constraints, SQL in general. May 16, 2016 at 9:00

DBA is a small acronym but a large role. At various times I have seen a DBA look after

  • storage
  • network
  • VMs
  • compute nodes
  • installation and configuration of the above
  • backups, and testing restores
  • DR strategy
  • enterprise data integrity
  • ETL
  • data security
  • data modelling, normalisation and database design
  • data tier programing
  • performance tuning
  • operational availability
  • replication
  • failovers
  • on-call support

.. and others besides. I cannot see any of these disappearing just because Oracle/ SQL Server/ PostgreSQL is replaced by MongoDB/ Cassandra/ CouchDB.

"Oh," but you say, "There's no schema. I don't have to do that modelling & design thing."

"You're deluded," I would reply. If the system is for, say, order processsing (and not order processing and chocolate cake recipies and cataloging selfies etc.), and The Business distinguishes Orders by a 7-digit integer Order Number, and each Order consists of one or more Order Lines (referencing one Product each), then you have a schema. Just because it's enforced in the application layer and not in the DBMS does not make it disappear. And somebody had better be writting those rules down, and confirming them with the users, and communicating them to the test team, and teaching newly-hired employees what they are, and getting them into the end-user documentation, and ensuring old data can still be read by the just-changed application. Just because the rules can be changed in application code alone, rather than application code and DBMS script, does not make any of that stuff any less important.

So, for my two cents' worth, despite its many, many benefits I don't believe this class of software removes any significant task traditionally done by a DBA in the RDBMS world. It may redistribute them onto people holding other job titles, and the tasks may become easier to perform or less intrusive into the SDLC.

As for adding tasks, there is the issue of maintaining compatibility with old data written according to a previous understanding of the business rules. An RDBMS would not have this problem as there is only one acceptable schema at any point in time.

  • Thanks for the reply Michael Green. The description of various task done by dbas is very nice, just hit the sweet spot. Upvoted the answer Just want to add, RDBMS databases will not be replaced by NoSql database yet, they are atleast a generation behind from doing that. I think we can safely call the current NoSql DBs as second genration, but more concepts,ideas and features are being added so that day may not be far off. And i doubt RDBMS companies are going site quite either, so from enterprise prespective, it will a mix of both for a long time.
    – Mechro
    May 14, 2016 at 13:18
  • I too strongly agree that database modelling and design is not going to disappear but they will be redistributed to a different portfolio. The DBA role is changing in NoSql space and those responsibilities are no longer with DBA .Most of these are done by small application teams driven by agile practice, as the application code is closely tied to database design and it is created and maintained by developers. This is the reason am waiting for some seasoned MongoDB DBA, to give me some pointers on the trade,out of the list which you have mentioned what they actually work on.
    – Mechro
    May 14, 2016 at 13:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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