The people who write the business logic and the people who do the analytics have different concerns. It's sometimes better to make different database choices for those two systems and just copy the data into the analytics system, rather than make a substandard choice of database to try to accommodate both.

If the devs want to use Mongo, it's their problem -- it shouldn't matter much to the analytics people, because they can just copy the data into a different database that fits their needs.

This is such a common issue there's an entire architecture pattern developed to solve it. https://en.wikipedia.org/wiki/Lambda_architecture . No classic ETL, and any number of folks/systems can plug into the messaging system and get all the data.

Fair enough. Perhaps there are other uses of mongo going on in addition to exporting it to a different database/format? Otherwise I'd be curious what justifies the mongo choice.

Certainly sometimes you are in a position where you just gotta take what other units in the org give you and deal with it.

But _someone_ in the org is hopefully in the position to be able to articulate why they are using mongo in the first place...

Except that devs have to do ETL every day so analysts can do their query work.

Which you'll likely want with any DB since analytics workloads are very different than the usual production DB workloads.

That can be automated.

In theory, yes; in practice, not really.

I tend to disagree. Having multiple automated ETL processes running for different projects/clients/colleagues I see that the code does not change as often, as I had anticipated.

Automation here (in my case) is a net win on time.

Why? Technically speaking, simple ETL is easy to automate and not too much maintenance headache.

"they can just copy the data into a different database that fits their needs."

That's easier said than done when your database is over 10 TB big.

You only need to copy the stuff that changed since the last time you copied stuff.

If you are really generating 10TB of data more than a few times a day, you can look into putting it in something like Kafka for real-time consumption by the analytics team instead of batch copying.

You just need to read the oplog, so it only needs to track your saves.

In general, you probably should have at least something in your stack which reads all changes from your DB, at the very least for backup reasons.

I agree with this perspective, and have been researching it more lately.

For better or for worse, MongoDB tends to be easier for developers move quickly, so it ends up getting adopted quite a bit. This is more about how to deal with it after it's already in your stack.

RethinkDB blows MongoDB on easy to use factor out by a large margin, with the upside of being a project focused on actual quality rather than pure marketing.

RethinkDB doesn't get enough love. It's rare to see anything pass the Jepsen tests to the degree that Rethink did: https://aphyr.com/posts/329-jepsen-rethinkdb-2-1-5

It's sad that, for a backend DB, correctness can be trumped by marketing.

What about Managed solutions, like DynamoDB? What could be easier than that - with cloud scale analytics opportunities to boot.