0

Two questions regarding selection a DB type and engine for the scenario when the Audit Trail functionality is a must:

  1. Is there any preference in DB type (NoSQL/Relational) choice when the Audit Trail is critical?

  2. Is it a common practice to use a MongoDB in a scenario when the Audit Trail is an obligatory feature?

As far as I know, MySQL and SQL Server offer such functionality, but I don't find such option in MongoDB features list.

|improve this question

closed as primarily opinion-based by mustaccio, John Eisbrener, LowlyDBA, Max Vernon, Stennie Jan 21 at 19:58

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

1

MongoDB does offer auditing features, as Stennie noted.

However I think it is worth mentioning that most major relational databases (Oracle, MSSQL, Postgres, etc.) are going to offer far more mature and feature rich auditing options that will probably be better suited for any legally required auditing.

I wouldn't choose NoSQL vs SQL solely based on auditing requirements, because that choice is far more complex. But I would feel better from an auditing perspective, especially if for legal compliance, using a more established relational DB.

A small example of this:

According to the MongoDB Audit documentation, auditing is only available in MongoDB Enterprise and MongoDB Atlas and does not include logout events.

SQL Server, meanwhile, does and has some level of auditing available in all versions from Express (free) to Enterprise.

|improve this answer
  • 1
    I'm sure there may be implementation differences between databases, but can you please include some factual points of comparison to substantiate "far more mature and feature rich auditing options"? Identifiable feature gaps would be useful to guide informed decisions; speculation on legal compliance solely based on tenure is opinion-based FUD. Although MongoDB is relatively new in the database world, it still has more than a decade of development history (with auditing available since 2014). – Stennie Jan 21 at 19:57
  • 2
    As an employee of Mongo, you seem to be taking it a bit personally. The lack of specificity of the question doesn't make sense for me to go into a detailed comparison with a random RDBMS, especially given that "I need to audit" is already very vague. But if you'd like to compare feature sets in your answer, you're more than welcome to. – LowlyDBA Jan 21 at 22:33
  • Not taking it personally - I was actually interested to see a factual comparison rather than opinion. Primarily opinion-based answers aren't on-topic for DBA StackExchange and I think there may be worthwhile differences to highlight. Since you alluded to more mature and feature rich options, it would have been helpful to have some examples. I was also trying to add context that auditing isn't a brand new feature in MongoDB. I'm happy to support informative responses, but I'm not aware of any specific legal or compliance concerns. In any case, the question is now too broad to be answerable :). – Stennie Jan 21 at 22:55
  • 2
    I've added an example, but I agree this question was destined to be closed as opinion based to begin with. If it was more narrow I would've been more specific from the get go for sure. – LowlyDBA Jan 21 at 23:25
  • Thanks for adding an example! Auditing and some other security/compliance features are indeed part of the MongoDB Enterprise & MongoDB Atlas feature sets, so are not included with the MongoDB Community server (as at MongoDB 4.0). FYI, MongoDB auditing does have full support for DML statements (which are logged via the authCheck audit event type). There is more detail in the documentation on configuring audit filters. For example: Filter on Read and Write Operations for a Collection. – Stennie Jan 21 at 23:40
2

MongoDB Enterprise and MongoDB Atlas both include auditing capability with options to to filter for audit events including schema (DDL) changes, CRUD operations, authentication & authorization, and replication/sharding commands.

Auditing was first included in MongoDB Enterprise 2.6 (March, 2014).

|improve this answer
  • Thanks for narrowing and answering my question. I added further question, which I intended to ask, but, apparently, failed to formulate at the beginning. – Mike B. Jan 21 at 13:01
  • 1
    @MikeB. Your edits make the question less specific and more opinion-based. Instead of asking if users have preferences, it would be more useful to highlight your specific auditing concerns. If auditing is critical for your use case, you would certainly select a solution that includes auditing and meets your general requirements. You should also choose a single comparison (MongoDB vs your auditing requirements, or MongoDB auditing versus MySQL auditing). Broad categories of NoSQL versus relational databases do not define auditing capabilities. – Stennie Jan 21 at 19:33

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