re: MongoDB has no use case VIEW POST

FULL DISCUSSION
 

Thank you for this! To be fair: I wouldn't call MongoDB useless. It's really pretty neat, and I think its value as a JSON document storage tool is real. That said...

I've been a developer for 25 years and a professor of software development for about 7. My latest round of classes includes a week of MySQL, then a week of MongoDB a few weeks later. Students commonly ask why people should bother with a relational database when they can have the ease of something like Mongo. And in the context of a few weeklong lessons, they're right! But I've had to explain that all of the hard stuff in relational databases (defined schema, foreign key based design, etc.) are there because they keep terrible things from happening to data, and that tossing that stuff out the window should only be done when you realize what you're giving up as well as what you're gaining.

 

Playing the devil's advocate here, Mongo is good for quick prototyping when you just launch a service. Once you have an idea of how the data is shaped, move to Postgres or MySQL. Postgres supports BSON/JSON datatype in later versions so Mongo is not needed for even that.

 

Postgres supports BSON/JSON datatype in later versions so Mongo is not needed for even that.

Epic! 😂

But then, once the data set gets too large, does it perform the same or better? What about map/reduce pipelines, as some comments have pointed out?

Mongo does have an easy way of sharding and clustering. Earlier versions of Mongo suffered from unreliability during network partitions but they have improved it.

There are Postgres extensions which do the same. It depends on what you are doing with the data though. For example, for many simple queries in Postgres you need to write separate application code to retrieve from Mongo, thus necessitating more nodes for the same task.

 

I agree that it's good for prototyping. What concerns me is:

1) The tool that you prototype with often ends up as the tool you use in production because you don't have the time to migrate it later. This has happened to all of us, I'm sure :)
2) Sometimes - especially with data models - people should really take time at the beginning and plan it out as much as possible. Having a schema-less database is more often an excuse to be lazy about planning, in my experience.

That said: I think that an experienced developer, who knows what NoSQL can and can't do, will be great with either type of db.

I agree. There is no better alternative to thinking about your data model upfront. Some devs I know who start out with NoSQL because of a (irrational) fear of changing a schema in production. Their process is to run an MVP for a month or so till feature requests slow down, then build the schema.

I can never convince myself that MongoDB saves non-trivial amounts of time when prototyping. How long does it take to design a schema? You anyway have to write migrations. And if something doesn't work, just drop the database, change the seeders a little bit, and rerun the migrations. For a prototype that takes a month to complete, MongoDB would save a day at best.

I agree! Especially given how good MySQL has gotten with migrations and the beginnings sharding.
I'm thinking of writing a post here where I beg the community to convince me that I'm wrong about NoSQL.

 

You're welcome! No, I don't think MongpDB is useless, but I don't understand it at all. That's why I started this discussion.

So, some of the comments here suggest that once a database is split up (which is often the case) you lose foreign keys anyway. And so, they say, MongoDB is better. What would you say to that?

Also, since you teach MongoDB, there has to be something to it. What is it good for? :)

code of conduct - report abuse