5 ms·

Today in 2017, there is no real reason to use MongoDB other than in prototyping. I am happily waiting until the final nail is put on the coffin of this overhype

Today in 2017, there is no real reason to use MongoDB other than in prototyping. I am happily waiting until the final nail is put on the coffin of this overhyped, flawed document store.

jamroom 9y ago
Why? I don't personally care if MongoDB succeeds or fails, but if they can listen to their users, fix their issues and come out the other end with a database that works as advertised what is wrong with that? Why is it so important to you that they fail?
- mikestew 9y ago
  Why is it so important to you that they fail? If it fails, then I can quit having the same discussions repeatedly as try to talk my co-workers out of using it.
optimuspaul 9y ago
"Today in 2017, there is no real reason to use Oracle other than in prototyping. I am happily waiting until the final nail is put on the coffin of this overhyped, flawed relational store." Point being you can say just about the same thing about any other database. They are all flawed for one reason or another. I happen to like Mongo quite a lot, but I rarely use it. You need to understand what situations it works best in and it's unfair to both it and yourself to generalize and wish it dead.
- flavio81 9y ago
  Oracle RDBMS isn't flawed. It is expensive, complex to configure/mantain/extend, expensive in licensing, expensive in storage, and also expensive. Did i mention expensive? PostgreSQL is eating Oracle's customers little by little. RDBMS aren't flawed at all, this is technology that has been perfected for the last 40 years. What is flawed is to think that relational data can be easily stored on a document store (typical mistake). I think document stores are a great thing; the only problem is that MongoDB isn't a good document store.
  - STRML 9y ago
    > I think document stores are a great thing; the only problem is that MongoDB isn't a good document store. To add to that - you know when you need one. If you don't know you need a document store, you don't need it. When you try a good document store, like Solr, you realize how appallingly limited Mongo really is. It's not suited for any practical use outside of demo apps.
    - threeseed 9y ago
      Solr is not a document store. It's a search engine. If you actually tried using it as one you would realise how ignorant your comment is. Both the Solr and ElasticSearch have gone on record before stating that it should never be used as the source of truth.
      - tinix 9y ago
        THIS, so much this!!!! I'm working on overhauling (rewriting, from scratch) a project right now where the previous developer decided in his infinite wisdom that using ES as a database was a good idea. I have tried repeatedly to explain to him, and the product owner, why using a search engine as a storage database is a horrific idea. Owner gets it, dev doesn't. I asked that dev if he could overhaul the project, what would he do, and he said "not use SQL at all, and use ES 100%". <_< I think this is the problem with Mongo too... you have people misusing it, and then want to throw the baby out with the bath water and act like Mongo is the problem, when really, the problem is how they are using it.
      - STRML 9y ago
        And yet - it can be used as one. "If you actually tried using it" is a wholly inappropriate thing to say to someone you don't know. We used it in a large application indexing & faceting millions of documents, and it works just fine for the practical purpose of querying & retrieving those documents. Of course, we did mate it with Postgres to build the full app. Each tool to its strength. There's no need for the vitriol.
  - optimuspaul 9y ago
- kentosi 9y ago
  "You need to understand what situations it works best in" I always hear this, but with no "such as" examples given. Could you please provide some?
  - nevi-me 9y ago
    The same example I provide everywhere. I have successfully used Mongo as a geospatial data store, where I have a public transit app/website, and most objects/documents have geospatial properties. Sure, there's PostGIS, but saving a GeoJSON multiline which I can slap an index on works for me. I have grown fond of Mongo because I've been using it for almost 5 years now. I know its limitations, and also what I can do in RDBMS that I can also do in it. I sometimes build OLAP logical models at work for clients, and most of what I touch at work is SQL, but sometimes when I start a project I use Mongo instead of SQL. It's only one use-case, but I hope it is something.
    - kentosi 9y ago
      Interesting. I haven't used JSON-stores because in my mind it always boils down to the question of how you would link entities together. I can't seem to get a good answer... so let me put this to you: In a standard RDBMS I would probably have a custom datatype for LatLon (or MGRS): create custom type LatLon(...) create table Person(id as int, name as string, location as LatLon) create table Shop(id as int, name as string, location as LatLon) Find everyone 10k around Macy's: select p.* from Person p inner join Shop s where s.name="Macy's" and with_distance(p.location, s.location, 10km) How would a JSON-store be better at managing this, given that with RDBMS systems you have indexes to help speed such cross-table looks?
STRML 9y ago
The hype is the real issue. Even today, the CTO appears to claim that 90% of apps aren't relational enough to need Mongo. I did a startup in 2011/2012 where we bought into the hype and used MongoDB & Node + Mongoose. It was horrific. Your app is relational, full stop. You would know if it wasn't. Do you have users? Do those users need to log in? Well, you now have access tokens related to users. Do those users need to create anything at all? You've now related those owned objects back to the user. We're talking the very basics of any application, and Mongo's support for it is basically nil. We went down the road of embedding relations inside the model (e.g. an "user" has multiple "tickets" to "events"), and then we'd just filter through the "events" table to find the related one. But what if the admin running the event wants a list of all the tickets for his event? We're talking webapp 101 stuff, but we had to write some really gnarly application logic and duplicate a bunch of data to make it fast. It was a complete waste of time. At the crux of this is a fallacy that easier is always better. It's not. There is a reason SQL databases are a little complicated to use - they have evolved over many decades to fit the needs of real applications. MongoDB is only barely removed from writing raw JSON arrays to disk, which is probably the simplest "database" imaginable. When you so callously discard the common wisdom on how to store data, you rediscover why it exists, the slow, hard way. 10gen made a business - and a fortune - out of misleading new developers.
- 43224gg252 9y ago
  >Do you have users? Do those users need to log in? Well, you now have access tokens related to users. Aren't those tokens supposed to be stored client side anyway? Aren't those tokens supposed to contain encoded information about the user that you decode server side? Why would you store the users token to begin with?
  - STRML 9y ago
    That's a matter of opinion and implementation. Not everyone uses JWTs. What if you want to invalidate all logged-in tokens for a user? You either need to store a blacklist (that's a relation) or set extremely short expiry times.
ojr 9y ago
Earlier in 2017, Atlassian acquired Trello (MongoDB, Node.js, Redis tech stack) for 425 Million dollars
- flavio81 9y ago
  ... So? Trello is a great product, and it will continue to be a great product no matter where it chooses to store its data.
- flukus 9y ago
  Funnily enough, the one feature I need to completely replace jira with trello is the ability to have the same card on multiple boards, but I guess they couldn't handle that kind of relational data.

Today in 2017, there is no real reason to use MongoDB other than in prototyping. I am happily waiting until the final nail is put on the coffin of this overhyped, flawed document store.

jamroom 9y ago

Why? I don't personally care if MongoDB succeeds or fails, but if they can listen to their users, fix their issues and come out the other end with a database that works as advertised what is wrong with that? Why is it so important to you that they fail?

mikestew 9y ago
Why is it so important to you that they fail? If it fails, then I can quit having the same discussions repeatedly as try to talk my co-workers out of using it.

optimuspaul 9y ago

"Today in 2017, there is no real reason to use Oracle other than in prototyping. I am happily waiting until the final nail is put on the coffin of this overhyped, flawed relational store." Point being you can say just about the same thing about any other database. They are all flawed for one reason or another. I happen to like Mongo quite a lot, but I rarely use it. You need to understand what situations it works best in and it's unfair to both it and yourself to generalize and wish it dead.

flavio81 9y ago
Oracle RDBMS isn't flawed. It is expensive, complex to configure/mantain/extend, expensive in licensing, expensive in storage, and also expensive. Did i mention expensive? PostgreSQL is eating Oracle's customers little by little. RDBMS aren't flawed at all, this is technology that has been perfected for the last 40 years. What is flawed is to think that relational data can be easily stored on a document store (typical mistake). I think document stores are a great thing; the only problem is that MongoDB isn't a good document store.
- STRML 9y ago
  > I think document stores are a great thing; the only problem is that MongoDB isn't a good document store. To add to that - you know when you need one. If you don't know you need a document store, you don't need it. When you try a good document store, like Solr, you realize how appallingly limited Mongo really is. It's not suited for any practical use outside of demo apps.
  - threeseed 9y ago
    Solr is not a document store. It's a search engine. If you actually tried using it as one you would realise how ignorant your comment is. Both the Solr and ElasticSearch have gone on record before stating that it should never be used as the source of truth.
    - tinix 9y ago
      THIS, so much this!!!! I'm working on overhauling (rewriting, from scratch) a project right now where the previous developer decided in his infinite wisdom that using ES as a database was a good idea. I have tried repeatedly to explain to him, and the product owner, why using a search engine as a storage database is a horrific idea. Owner gets it, dev doesn't. I asked that dev if he could overhaul the project, what would he do, and he said "not use SQL at all, and use ES 100%". <_< I think this is the problem with Mongo too... you have people misusing it, and then want to throw the baby out with the bath water and act like Mongo is the problem, when really, the problem is how they are using it.
    - STRML 9y ago
      And yet - it can be used as one. "If you actually tried using it" is a wholly inappropriate thing to say to someone you don't know. We used it in a large application indexing & faceting millions of documents, and it works just fine for the practical purpose of querying & retrieving those documents. Of course, we did mate it with Postgres to build the full app. Each tool to its strength. There's no need for the vitriol.
- optimuspaul 9y ago
kentosi 9y ago
"You need to understand what situations it works best in" I always hear this, but with no "such as" examples given. Could you please provide some?
- nevi-me 9y ago
  The same example I provide everywhere. I have successfully used Mongo as a geospatial data store, where I have a public transit app/website, and most objects/documents have geospatial properties. Sure, there's PostGIS, but saving a GeoJSON multiline which I can slap an index on works for me. I have grown fond of Mongo because I've been using it for almost 5 years now. I know its limitations, and also what I can do in RDBMS that I can also do in it. I sometimes build OLAP logical models at work for clients, and most of what I touch at work is SQL, but sometimes when I start a project I use Mongo instead of SQL. It's only one use-case, but I hope it is something.
  - kentosi 9y ago
    Interesting. I haven't used JSON-stores because in my mind it always boils down to the question of how you would link entities together. I can't seem to get a good answer... so let me put this to you: In a standard RDBMS I would probably have a custom datatype for LatLon (or MGRS): create custom type LatLon(...) create table Person(id as int, name as string, location as LatLon) create table Shop(id as int, name as string, location as LatLon) Find everyone 10k around Macy's: select p.* from Person p inner join Shop s where s.name="Macy's" and with_distance(p.location, s.location, 10km) How would a JSON-store be better at managing this, given that with RDBMS systems you have indexes to help speed such cross-table looks?

STRML 9y ago

The hype is the real issue. Even today, the CTO appears to claim that 90% of apps aren't relational enough to need Mongo. I did a startup in 2011/2012 where we bought into the hype and used MongoDB & Node + Mongoose. It was horrific. Your app is relational, full stop. You would know if it wasn't. Do you have users? Do those users need to log in? Well, you now have access tokens related to users. Do those users need to create anything at all? You've now related those owned objects back to the user. We're talking the very basics of any application, and Mongo's support for it is basically nil. We went down the road of embedding relations inside the model (e.g. an "user" has multiple "tickets" to "events"), and then we'd just filter through the "events" table to find the related one. But what if the admin running the event wants a list of all the tickets for his event? We're talking webapp 101 stuff, but we had to write some really gnarly application logic and duplicate a bunch of data to make it fast. It was a complete waste of time. At the crux of this is a fallacy that easier is always better. It's not. There is a reason SQL databases are a little complicated to use - they have evolved over many decades to fit the needs of real applications. MongoDB is only barely removed from writing raw JSON arrays to disk, which is probably the simplest "database" imaginable. When you so callously discard the common wisdom on how to store data, you rediscover why it exists, the slow, hard way. 10gen made a business - and a fortune - out of misleading new developers.

43224gg252 9y ago
>Do you have users? Do those users need to log in? Well, you now have access tokens related to users. Aren't those tokens supposed to be stored client side anyway? Aren't those tokens supposed to contain encoded information about the user that you decode server side? Why would you store the users token to begin with?
- STRML 9y ago
  That's a matter of opinion and implementation. Not everyone uses JWTs. What if you want to invalidate all logged-in tokens for a user? You either need to store a blacklist (that's a relation) or set extremely short expiry times.

ojr 9y ago

Earlier in 2017, Atlassian acquired Trello (MongoDB, Node.js, Redis tech stack) for 425 Million dollars

flavio81 9y ago
... So? Trello is a great product, and it will continue to be a great product no matter where it chooses to store its data.
flukus 9y ago
Funnily enough, the one feature I need to completely replace jira with trello is the ability to have the same card on multiple boards, but I guess they couldn't handle that kind of relational data.