DynamoDB is a lot more explicit about its tradeoffs. Much of the backlash against Mongo was because it basically claimed to be well-suited to any use case, when its sweet spot was really far narrower. To be successful with Mongo, you need to design the entire app around its limitations, but those limitations were initially downplayed and obscured.

People were convinced that Mongo was a good choice as a default, general purpose db, when it clearly wasn’t for about a million reasons.

I don’t think DynamoDB is marketed or viewed in the same way. The docs are pretty clear about needing to design your data model to specifically work well with Dynamo. People using it seem to generally be aware of its limitations, and deliberately choose to accept them for the sake of performance and scalability. At least that’s my perception.

> I don’t think DynamoDB is marketed or viewed in the same way. The docs are pretty clear about needing to design your data model to specifically work well with Dynamo.

More importantly, AWS is very explicit in letting newcomers be perfectly aware that DynamoDB's usecases are, that they are very specific niche use cases, and that if users require schemas and joins then they should just stick with either relational databases or graph databases.

Those who overpromise will always disappoint.

What are those good use-cases for mongo?

Basically when speed and horizontal scalability are very important, and consistency/durability are less important. It’s also pretty good for unstructured or irregularly structured data that’s hard to write a schema for.

Web scraping or data ingestion from apis might be a reasonable use case. Or maybe consumer apps/games where occasional data loss or inconsistency isn’t a big deal.

It can also be used effectively as a kind of durable cache (with a nice query language) in place of redis/memcached if you give it plenty of ram. While its guarantees or lack thereof aren’t great for a database, they’re pretty good for a cache.

I worked for a big news website- we used mongodb for pixel tracking data.

I went on to work at mongodb

DynamoDB is a completely different beast and would use no other data store unless I had to. It can pretty much handle any transactional workload I need.

It's cheap, its fast and it scales super high. Don't need much more

DynamoDB is consistent and scalable, not fast and cheap.

DDB is great for storing data that is required to be scalable and never needs to be joined. Add in DAX, developer time necessary to orchestrate transactions, calculate the scaling costs and...that's how AWS gets you.

Plus, local development requires half-complete emulators or a hosted database you're charged for.

No, maybe people should think twice about DynanoDB.

This came up in a thread a few days back, but people considering it should note that Dynamo’s transactions are limited to 25 rows. That may be enough for most operations, but I definitely wouldn’t say it can handle “any transactional workload”. I ran into this limit pretty quickly when trying it out.

I'm curious as well, since my company is moving from Postgres to DynamoDB.

Could you share your use case?