7 ms·

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

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 later on, but the trade-off is that it likely allowed the company to exist at all – the founder being more of a domain expert than a technical expert, but being able to use it to scale their idea pretty quickly without having to pay much attention to all that tedious "reliability" and "safety" nonsense :) That said, it's not something that an experienced developer should be using for anything nowadays, and the solution might be to ensure that competing alternatives (like Postgres) can learn from why MongoDB became popular and seek to solve some of the pain points in their own implementations.

rwmj 8y ago
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 the best part of a year.
- k__ 8y ago
  I worked in such a company too. Every time we wanted to do something new a founder would say "Domino can do this!" and then they would spend the whole weekend setting it up for what we were trying to do. All because we were some kind of IBM partner and they wanted to please the big wigs.
  - bluedino 8y ago
    This happened from 2000-2010 but with Sharepoint.
  - teh_klev 8y ago
    Once upon a time in a job far away, about 15% of my time was allocated to being the company sysadmin, and as all good sysadmins do, reduced that time to about 5%.....until.... One day, and despite my protests, I had to bin our perfectly fine and well maintained/loved Exchange server for fricken Notes/Domino just because one of the investors had some free licenses. After the migration, everyone hated it and I was persona non grata seeing as it was me who had to switch us over. It never worked properly. I left not long afterwards and the poor sod who was my replacement had the joy of looking after that dumpster fire. edit: opening sentence
    - fouc 8y ago
      I wonder if that poor sod will be an HN reader too, and end up seeing your post
- ptero 8y ago
  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.
- bunderbunder 8y ago
  I used to work for a company that occasionally had to interact with others' Lotus Notes setups. At one point, there was some discussion about migrating one of our systems to a document store. There was a fair bit of back-and-forth at first. After someone pointed out that Lotus Notes is basically a document store, though, the idea was dropped more-or-less immediately and unanimously. I can see the attraction when you're just starting out on a project, but we had just spent way too much time dealing with what they're like after they've had time to mature into full-blown quagmires.
a13n 8y ago
> 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.
StavrosK 8y ago
In my experience, when there's something that offers additional guarantees for additional work, it's very rarely the right solution to completely forgo the guarantees. This goes for schemas, typing in languages, etc. Maybe the additional work is too much for the benefit, but it's not that there's no benefit. Forgoing the guarantees usually leads to much more extra work. I think Python's "no types anywhere" was a reaction to Java's "types everywhere", but neither is optimal. Something with gradual typing or type inference has much more bang for its buck, so whenever I see "I use MongoDB because there's no schema to worry about", I always think that it's going to come back and bite someone in the ass.
- kdbeall2 8y ago
  > I think Python’s “no types anywhere” was a reaction to Java’s “types everywhere” To nitpick, Python actually came before Java. But, the overall sentiment is something I agree with.
  - StavrosK 8y ago
    Oh yeah, that's not nitpicking, that's a good point. Replace "Java" with any type-verbose language of the era.
rooam-dev 8y ago
Could you elaborate please on the untold pain part? We use Mongo as our primary storage at the moment and I would like to avoid painful issues. Thank you in advance. On the other note, I keep seeing people recommending Postgres, but to me that is apples vs. oranges. Just because it has json storage doesn't make it a replacement. How much effort and money a company needs to keep a replicated Postres cluster vs. Mongo? In one of my previous jobs we had to hire a consultant to do that. With Mongo pretty much any experience dev could do that. My personal view is that MongoDB's main advantage is its flexibility. It allows teams to shape and evolve the product as needed. When specific features/parts require new solutions, new solutions can be used (financial transactions, etc). Features that allowed us to leverage what we have instead of researching new tools were: 1. Schemaless - Logic is in the app; Gives visibility; Can be tested; Less migration headaches; Easier to evolve your architecture. 2. Indexed arrays, attributes (name, value pair) - Allows to be more creative (add tagging system to any type of data you have) 3. Aggregation - basic BI could be done from day one, which business can get value sooner. Of course, everyone's millage varies
- wefarrell 8y ago
  It’s been a while since I’ve worked with Mongo but I remember having significant performance issues with indexed arrays, particularly for compound indexes. They weren’t solvable by any tweaking, it was a fundamental problem with that feature, to the point where we wondered why they allowed it at all. It’s possible they’ve fixed it by now.
  - rooam-dev 8y ago
    Thanks, we'll add to our "eye keeping" list.
    - dajohnson89 8y ago
      If you "abuse" MongoDB and treat it like a relational store, certain queries will be difficult to write and very poorly performing. At least that was our experience, 2 years ago.
api 8y ago
It was often the best choice for getting a product up and running fast and rapid iteration for exactly the reasons you mention. Once the schema solidified, it stopped being the right choice. We (ZeroTier) experienced the same thing but with RethinkDB, a similar schema-less database. We outgrew it when we needed something more solid and more reliable and we had a pretty settled schema.
duxup 8y ago
As a n00b when it comes to web development I've sort of given up on fretting more than "too much" about "Is this the best way?" and focused on "let's try some stuff and it doesn't work I'll learn from it and make a better choice when I come to it". There seems to be a cost associated with evaluating optimal paths. Personally I get SQL (well enough to use it) and I can work with so I don't bother with MongoDB much, but if there's someone who doesn't and needs to get a project going and the alternative is lots of delay or no project, yeah why not. I feel like when it comes to development people really gripe about the best choices ... when the non best choices might just as well be looked at as a path to the best choices, and there's a lot of value in that. Now that's all within the context of weighing the costs to ... everyone. Hobby project few if anyone will see, hey who cares. Work project, a lot more diligence and consultation with others ;)
- Scarbutt 8y ago
  Perfect is the enemy of good. I know this but I keep ignoring it ¯\_(ツ)_/¯
  - duxup 8y ago
    That and sometimes what you think is perfect ... isn't always it. I've gotten time to make something polished and perfect and came out with "uh you know that first run prototype ... might be better in some ways".
ex_ex_nihilo 8y ago
Postgres is not an alternative to Mongo, though. Provide a noSQL alternative if you want an alternative. RDBs and non-RDBs seek to address different sets of problems, and sometimes you do not want or need a relational database.
- harunurhan 8y ago
  Postgres has JSON support. In fact Amazon's documentdb which is alternative to Mongo, is built on top of Postgres AFAIK.
  - thawkins 8y ago
    Its built ontop of aurora, which is amazons own datastore.
- zkomp 8y ago
  But postgres actually is that with json and jsonb. The postgres developers are also very focused on providing a better alternative to mongo. Afaik similarly configured postgres also challenge or beat mongodb in performance.
  - ex_ex_nihilo 8y ago
    Cool thanks, I did not know about that.
- matthewmacleod 8y ago
  In what situations do you feel MongoDB is a better solution than Postgres? The latter is both relational and document-oriented as required.
  - tracker1 8y ago
    Setting up a simple cluster without relying on addons, or having to worry about which server in the cluster your writes are going to (bisected application configurations)
Thaxll 8y ago
"passable clustering" you talk about PG which has nothing, so when you start to re-implement sharding yourself you're in trouble. Fortnite uses MongoDB for everything, they have a huge load ( 7.5M CCU is insane ) and don't have more problems than if they choose something else. MongoDB gets bad press on Reddit / HN probably because of past marketing campaigns, but nowdays it's a very solid solution.
- mbell 8y ago
  > "passable clustering" you talk about PG which has nothing, so when you start to re-implement sharding yourself you're in trouble. Or you can just use Citus.
  - Thaxll 8y ago
    Which is not PG anymore.
    - stingraycharles 8y ago
      It's dead easy to migrate an existing PostgreSQL install to Citus (application code can all stay the same), so it's a great way to scale your application when you need it, and at the same time just use PostgreSQL for when you don't need scale yet (99% of all apps).
    - GordonS 8y ago
      I thought it was implemented as an extension, rather than a separate product? I'd say that's still "Postgres"
    - manigandham 8y ago
      Citus is an extension to Postgres. It is still PG, and has the same scaling semantics as a MongoDB replica set that that point for distributed tables.
- matthewmacleod 8y ago
  You can use Citus, as others have mentioned, or something like BDR – but bear in mind that vanilla Postgres will happily do big pile of hot standby servers for scaling reads, and will scale vertically very well. You might have a case in which you need something faster – I'd argue that there are still better solutions, but YMMV.
deleted 8y ago
[deleted]
zjaffee 8y ago
I have to absolutely disagree with the point you're making about mongodb never being something an experienced developers should use. An experience developer understands when the goal is to deliver something as fast as possible vs building something more resilient. If you're building an internal tool, particularly one that won't be storing data that would later be used for analytics, there's absolutely no reason to not go with mongodb over a relational database considering you can get hosted versions of both for the same price. For a less than a week long project, you could be saving at least 20% of the time spent not having to worry about a datamodel.
- matthewmacleod 8y ago
  You could be saving at least 20% of the time spent not having to worry about a datamodel. You are not "not worrying about a datamodel" – you are just ignoring the data model that exists. And that overhead, if it exists at all, is far less than "20%".
  - tracker1 8y ago
    s/datamodel/data-mapping/
commandlinefan 8y ago
That's what I've seen. I've been involved with efforts to do something that an actual RDBMS is designed for with Mongo, Cassandra, Couchbase, Redis and even ElasticSearch - in every case we ended up re-creating so much of the functionality that is built into an RDBMS that the effort took much longer than it would have taken if we'd used MySQL or Postgres, in addition to being much slower (not to say anything of how proprietary and locked in the solution ended up being). There are good use cases for all of these products, and when used the way they were designed to be used, they're great; they're just not used that way very often (that I've seen).
tracker1 8y ago
I disagree... I think if you have an application where you have several variants of a type of document in a handful of collections, MongoDB is a great fit (think classifieds, or other storefront). It the structures don't nest too deeply, and they vary a bit from one subtype to another, it can work very well. And scale better in the box than many alternatives (a shortfall of PostgreSQL imho). It's a combination of factors. I still mostly reach for more traditional SQL options (including SQLite). It just depends on the needs of the application, the costs associated and the skill and experience of the developers working on the application. I would still reach for Mongo first for a handful of application types, I do wish that RethinkDB had the marketing effort/money/skill that Mongo did, as I think they were more solid on the technology, and the admin interfaces are great. I'd love to see a mid-scale vendor pick up the tech and run with it.

rwmj 8y ago

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 the best part of a year.

k__ 8y ago
I worked in such a company too. Every time we wanted to do something new a founder would say "Domino can do this!" and then they would spend the whole weekend setting it up for what we were trying to do. All because we were some kind of IBM partner and they wanted to please the big wigs.
- bluedino 8y ago
  This happened from 2000-2010 but with Sharepoint.
- teh_klev 8y ago
  Once upon a time in a job far away, about 15% of my time was allocated to being the company sysadmin, and as all good sysadmins do, reduced that time to about 5%.....until.... One day, and despite my protests, I had to bin our perfectly fine and well maintained/loved Exchange server for fricken Notes/Domino just because one of the investors had some free licenses. After the migration, everyone hated it and I was persona non grata seeing as it was me who had to switch us over. It never worked properly. I left not long afterwards and the poor sod who was my replacement had the joy of looking after that dumpster fire. edit: opening sentence
  - fouc 8y ago
    I wonder if that poor sod will be an HN reader too, and end up seeing your post
ptero 8y ago
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.
bunderbunder 8y ago
I used to work for a company that occasionally had to interact with others' Lotus Notes setups. At one point, there was some discussion about migrating one of our systems to a document store. There was a fair bit of back-and-forth at first. After someone pointed out that Lotus Notes is basically a document store, though, the idea was dropped more-or-less immediately and unanimously. I can see the attraction when you're just starting out on a project, but we had just spent way too much time dealing with what they're like after they've had time to mature into full-blown quagmires.

a13n 8y ago

> 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.

StavrosK 8y ago

In my experience, when there's something that offers additional guarantees for additional work, it's very rarely the right solution to completely forgo the guarantees. This goes for schemas, typing in languages, etc. Maybe the additional work is too much for the benefit, but it's not that there's no benefit. Forgoing the guarantees usually leads to much more extra work. I think Python's "no types anywhere" was a reaction to Java's "types everywhere", but neither is optimal. Something with gradual typing or type inference has much more bang for its buck, so whenever I see "I use MongoDB because there's no schema to worry about", I always think that it's going to come back and bite someone in the ass.

kdbeall2 8y ago
> I think Python’s “no types anywhere” was a reaction to Java’s “types everywhere” To nitpick, Python actually came before Java. But, the overall sentiment is something I agree with.
- StavrosK 8y ago
  Oh yeah, that's not nitpicking, that's a good point. Replace "Java" with any type-verbose language of the era.

rooam-dev 8y ago

Could you elaborate please on the untold pain part? We use Mongo as our primary storage at the moment and I would like to avoid painful issues. Thank you in advance. On the other note, I keep seeing people recommending Postgres, but to me that is apples vs. oranges. Just because it has json storage doesn't make it a replacement. How much effort and money a company needs to keep a replicated Postres cluster vs. Mongo? In one of my previous jobs we had to hire a consultant to do that. With Mongo pretty much any experience dev could do that. My personal view is that MongoDB's main advantage is its flexibility. It allows teams to shape and evolve the product as needed. When specific features/parts require new solutions, new solutions can be used (financial transactions, etc). Features that allowed us to leverage what we have instead of researching new tools were: 1. Schemaless - Logic is in the app; Gives visibility; Can be tested; Less migration headaches; Easier to evolve your architecture. 2. Indexed arrays, attributes (name, value pair) - Allows to be more creative (add tagging system to any type of data you have) 3. Aggregation - basic BI could be done from day one, which business can get value sooner. Of course, everyone's millage varies

wefarrell 8y ago
It’s been a while since I’ve worked with Mongo but I remember having significant performance issues with indexed arrays, particularly for compound indexes. They weren’t solvable by any tweaking, it was a fundamental problem with that feature, to the point where we wondered why they allowed it at all. It’s possible they’ve fixed it by now.
- rooam-dev 8y ago
  Thanks, we'll add to our "eye keeping" list.
  - dajohnson89 8y ago
    If you "abuse" MongoDB and treat it like a relational store, certain queries will be difficult to write and very poorly performing. At least that was our experience, 2 years ago.

api 8y ago

It was often the best choice for getting a product up and running fast and rapid iteration for exactly the reasons you mention. Once the schema solidified, it stopped being the right choice. We (ZeroTier) experienced the same thing but with RethinkDB, a similar schema-less database. We outgrew it when we needed something more solid and more reliable and we had a pretty settled schema.

duxup 8y ago

As a n00b when it comes to web development I've sort of given up on fretting more than "too much" about "Is this the best way?" and focused on "let's try some stuff and it doesn't work I'll learn from it and make a better choice when I come to it". There seems to be a cost associated with evaluating optimal paths. Personally I get SQL (well enough to use it) and I can work with so I don't bother with MongoDB much, but if there's someone who doesn't and needs to get a project going and the alternative is lots of delay or no project, yeah why not. I feel like when it comes to development people really gripe about the best choices ... when the non best choices might just as well be looked at as a path to the best choices, and there's a lot of value in that. Now that's all within the context of weighing the costs to ... everyone. Hobby project few if anyone will see, hey who cares. Work project, a lot more diligence and consultation with others ;)

Scarbutt 8y ago
Perfect is the enemy of good. I know this but I keep ignoring it ¯\_(ツ)_/¯
- duxup 8y ago
  That and sometimes what you think is perfect ... isn't always it. I've gotten time to make something polished and perfect and came out with "uh you know that first run prototype ... might be better in some ways".

ex_ex_nihilo 8y ago

Postgres is not an alternative to Mongo, though. Provide a noSQL alternative if you want an alternative. RDBs and non-RDBs seek to address different sets of problems, and sometimes you do not want or need a relational database.

harunurhan 8y ago
Postgres has JSON support. In fact Amazon's documentdb which is alternative to Mongo, is built on top of Postgres AFAIK.
- thawkins 8y ago
  Its built ontop of aurora, which is amazons own datastore.
zkomp 8y ago
But postgres actually is that with json and jsonb. The postgres developers are also very focused on providing a better alternative to mongo. Afaik similarly configured postgres also challenge or beat mongodb in performance.
- ex_ex_nihilo 8y ago
  Cool thanks, I did not know about that.
matthewmacleod 8y ago
In what situations do you feel MongoDB is a better solution than Postgres? The latter is both relational and document-oriented as required.
- tracker1 8y ago
  Setting up a simple cluster without relying on addons, or having to worry about which server in the cluster your writes are going to (bisected application configurations)

Thaxll 8y ago

"passable clustering" you talk about PG which has nothing, so when you start to re-implement sharding yourself you're in trouble. Fortnite uses MongoDB for everything, they have a huge load ( 7.5M CCU is insane ) and don't have more problems than if they choose something else. MongoDB gets bad press on Reddit / HN probably because of past marketing campaigns, but nowdays it's a very solid solution.

mbell 8y ago
> "passable clustering" you talk about PG which has nothing, so when you start to re-implement sharding yourself you're in trouble. Or you can just use Citus.
- Thaxll 8y ago
  Which is not PG anymore.
  - stingraycharles 8y ago
    It's dead easy to migrate an existing PostgreSQL install to Citus (application code can all stay the same), so it's a great way to scale your application when you need it, and at the same time just use PostgreSQL for when you don't need scale yet (99% of all apps).
  - GordonS 8y ago
    I thought it was implemented as an extension, rather than a separate product? I'd say that's still "Postgres"
  - manigandham 8y ago
    Citus is an extension to Postgres. It is still PG, and has the same scaling semantics as a MongoDB replica set that that point for distributed tables.
matthewmacleod 8y ago
You can use Citus, as others have mentioned, or something like BDR – but bear in mind that vanilla Postgres will happily do big pile of hot standby servers for scaling reads, and will scale vertically very well. You might have a case in which you need something faster – I'd argue that there are still better solutions, but YMMV.

deleted 8y ago

[deleted]

zjaffee 8y ago

I have to absolutely disagree with the point you're making about mongodb never being something an experienced developers should use. An experience developer understands when the goal is to deliver something as fast as possible vs building something more resilient. If you're building an internal tool, particularly one that won't be storing data that would later be used for analytics, there's absolutely no reason to not go with mongodb over a relational database considering you can get hosted versions of both for the same price. For a less than a week long project, you could be saving at least 20% of the time spent not having to worry about a datamodel.

matthewmacleod 8y ago
You could be saving at least 20% of the time spent not having to worry about a datamodel. You are not "not worrying about a datamodel" – you are just ignoring the data model that exists. And that overhead, if it exists at all, is far less than "20%".
- tracker1 8y ago
  s/datamodel/data-mapping/

commandlinefan 8y ago

That's what I've seen. I've been involved with efforts to do something that an actual RDBMS is designed for with Mongo, Cassandra, Couchbase, Redis and even ElasticSearch - in every case we ended up re-creating so much of the functionality that is built into an RDBMS that the effort took much longer than it would have taken if we'd used MySQL or Postgres, in addition to being much slower (not to say anything of how proprietary and locked in the solution ended up being). There are good use cases for all of these products, and when used the way they were designed to be used, they're great; they're just not used that way very often (that I've seen).

tracker1 8y ago

I disagree... I think if you have an application where you have several variants of a type of document in a handful of collections, MongoDB is a great fit (think classifieds, or other storefront). It the structures don't nest too deeply, and they vary a bit from one subtype to another, it can work very well. And scale better in the box than many alternatives (a shortfall of PostgreSQL imho). It's a combination of factors. I still mostly reach for more traditional SQL options (including SQLite). It just depends on the needs of the application, the costs associated and the skill and experience of the developers working on the application. I would still reach for Mongo first for a handful of application types, I do wish that RethinkDB had the marketing effort/money/skill that Mongo did, as I think they were more solid on the technology, and the admin interfaces are great. I'd love to see a mid-scale vendor pick up the tech and run with it.