Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Was MongoDB Ever the Right Choice?

simplethread.com

Post reply on HN
Print view View original

81–90 of 224 posts

Re: Was MongoDB Ever the Right Choice?

#81

Post by a13n »

matthewmacleod wrote: post #30

I would argue that MongoDB is not—and has never been—the best choice for solving any particular technical problem. But it had some other "advantages" over other, better solutions – in that it was easier to set up, didn't require schema definition, had a passable clustering story etc. I have worked with at least one company that had been built using MongoDB as a primary data store from day one. This caused untold pain…

> That said, it's not something that an experienced developer should be using for anything nowadays

Why not? You've said a lot of stuff, but haven't really backed it up with any reasons other than anecdotal experience.

Re: Was MongoDB Ever the Right Choice?

#82

Post by ptero »

rwmj wrote: post #43
matthewmacleod wrote: post #30

I would argue that MongoDB is not—and has never been—the best choice for solving any particular technical problem. But it had some other "advantages" over other, better solutions – in that it was easier to set up, didn't require schema definition, had a passable clustering story etc. I have worked with at least one company that had been built using MongoDB as a primary data store from day one. This caused untold pain…

I once worked for a company where Lotus Notes fulfilled a similar role (this was back in the late 1990s). Eventually they ran an entire free to sign up web-based email system using 4 giant Notes instances. It was an absolute nightmare, but probably the company would never have happened otherwise because Notes was all that the founders knew. My job was managing the migration off to a normal SQL database, which took th…

There are, I am sure, numerous stories like this. I know of a case where discussions and votes were conducted using a shared yahoo mail account -- a bunch of folks would just log in and note their preferences in the draft email with subject "Vote for X". A single account, shared password (in theory one could erase/edit previous votes), but it worked just fine as the group was small and no one wanted to do mischief.

The flip side of this is that beyond a certain size such initial designs are a killer. And a company should monitor time sunk into maintaining such things, prioritize those that are most expensive and fix them as soon as it can afford to. And this is often done way too late, causing harm that can be impossible to repair. My 2c.

Re: Was MongoDB Ever the Right Choice?

#83

Post by teh_klev »

scarface74 wrote: post #60
a13n wrote: post #52

These "caveats" are mostly false, or outdated. > Loss of transactions MongoDB 4.0 supports ACID transactions: https://www.mongodb.com/transactions > Loss of relational integrity (foreign keys) > Having a database enforce these relationships can offload a lot of work from your application, and therefore from your engineers. I've never seen anyone use MongoDB without also using something like Mongoose where you get all…

Lack of ability to enforce structure - when using Mongo with C# you’re working with a strongly typed Collection where types are enforced by the compiler when you add records and a strongly type IMongoQueryable when you query the database. Custom query language - I bet he also hates ElasticSearch. But again, using C# and the first party Mongo LINQ library, you are working with LINQ - the same built in C# query languag…

This is fine and well if you're using your team's language tooling to enforce these things. But the moment you're outside those boundaries all bets are off.

Re: Was MongoDB Ever the Right Choice?

#84

Post by tjpnz »

While I think MongoDB is deserving of a lot of the criticism it receives I think the bigger issue is with those who adopt it without a full understanding of their data and the use cases they might need to implement. There are countless stories now from people who assumed their data wasn't relational only to discover much later on that the opposite was true. There are cases where a document oriented datastore could be the way to go but everything I've read seems to suggest that they're in a minority.

Re: Was MongoDB Ever the Right Choice?

#85

Post by a13n »

tjpnz wrote: post #84

While I think MongoDB is deserving of a lot of the criticism it receives I think the bigger issue is with those who adopt it without a full understanding of their data and the use cases they might need to implement. There are countless stories now from people who assumed their data wasn't relational only to discover much later on that the opposite was true. There are cases where a document oriented datastore could be…

There's no reason you can't use MongoDB with relational data.

Foreign references? They've got them. https://docs.mongodb.com/manual/reference/database-reference...

ACID transactions? They've got them. https://www.mongodb.com/transactions

Re: Was MongoDB Ever the Right Choice?

#86

Post by woofie11 »

tjpnz wrote: post #84

While I think MongoDB is deserving of a lot of the criticism it receives I think the bigger issue is with those who adopt it without a full understanding of their data and the use cases they might need to implement. There are countless stories now from people who assumed their data wasn't relational only to discover much later on that the opposite was true. There are cases where a document oriented datastore could be…

I don't think the document addresses key issues with Mongo: Poor technical implementation.

There are countless stories of odd performance issues, occasional data loss, and similar.

postgresql can handle JSON documents with none of that and better performance. If you're not doing a lot of relational work, relational databases shard really nicely for arbitrary scalability. etc.

I love the concept of Mongo, but when I used it, I found it unusable. I switched back to relational databases as well as S3. On the whole, it just works better.

Re: Was MongoDB Ever the Right Choice?

#87

Post by StevePerkins »

a13n wrote: post #52

These "caveats" are mostly false, or outdated. > Loss of transactions MongoDB 4.0 supports ACID transactions: https://www.mongodb.com/transactions > Loss of relational integrity (foreign keys) > Having a database enforce these relationships can offload a lot of work from your application, and therefore from your engineers. I've never seen anyone use MongoDB without also using something like Mongoose where you get all…

Most of this counterpoint seems to revolve around the third-party library Mongoose.

I'm not that deeply familiar with MongoDB first-hand. Is Mongoose something you can bring to bear as a plugin on the database server? Or is it strictly a client application library?

Because to analogize to relational databases:

* If you cite PL/SQL, T-SQL, PL/pgSQL, etc as solutions for SQL's shortcomings, then you have a point.

* But if you point to JPA/Hibernate, Entity Framework, SQLAlchemy, or just raw hand-rolled application-tier logic, then that's no counterpoint at all. Because it means that only one client can safely use the database, and that assumption breaks down in the real world beyond the toy proof-of-concept stage.

Re: Was MongoDB Ever the Right Choice?

#88

Post by tjpnz »

a13n wrote: post #85
tjpnz wrote: post #84

While I think MongoDB is deserving of a lot of the criticism it receives I think the bigger issue is with those who adopt it without a full understanding of their data and the use cases they might need to implement. There are countless stories now from people who assumed their data wasn't relational only to discover much later on that the opposite was true. There are cases where a document oriented datastore could be…

There's no reason you can't use MongoDB with relational data. Foreign references? They've got them. https://docs.mongodb.com/manual/reference/database-reference... ACID transactions? They've got them. https://www.mongodb.com/transactions

But why wouldn't I just use Postgres instead?

Re: Was MongoDB Ever the Right Choice?

#89

Post by felixfbecker »

scarface74 wrote: post #63
dijit wrote: post #17

Since everyone is sharing their opinion and experience with mongodb I think I’ll share mine. As an appeal to authority I would like to mention that I have relevant vocational qualifications on the subject (more geared towards scalability and operations). Although I don’t believe it really matters - it will to those who assume I don’t understand best practice. MongoDB itself is not /really/ a valid choice in many scen…

I’m a big fan of Mongo for the use case you described - searching by ID and all information in one document. But people don’t seem to understand that there are plenty of scenarios where you really either don’t know the schemes in advance and/or the “schema” is defined by an external source. I worked for a company that sold software that allowed users to create forms that could be filled out either on the web or via a…

PostgreSQL's JSON columns are pretty powerful

Re: Was MongoDB Ever the Right Choice?

#90

Post by scarface74 »

teh_klev wrote: post #83
scarface74 wrote: post #60

Earlier quoted context omitted.

Lack of ability to enforce structure - when using Mongo with C# you’re working with a strongly typed Collection where types are enforced by the compiler when you add records and a strongly type IMongoQueryable when you query the database. Custom query language - I bet he also hates ElasticSearch. But again, using C# and the first party Mongo LINQ library, you are working with LINQ - the same built in C# query languag…

This is fine and well if you're using your team's language tooling to enforce these things. But the moment you're outside those boundaries all bets are off.

Even if I’m using an RDMS, as a tech lead, I still enforce only one “service” writes to a particular set of domain related tables. I don’t mean an http microservice necessarily. It could very well be a separate project/module in a monolith or even a package/module shared via an internal package manager.

But I would never use a weakly typed language and a weakly typed data store. That’s a mess waiting to happen.

Post reply on HN