11 ms·

Is it me..or does Mongo not seem as relevent and 'hip' as it once was... I mean I feel postgres is much more solid, and you can combine some of the aspects of d

Is it me..or does Mongo not seem as relevent and 'hip' as it once was... I mean I feel postgres is much more solid, and you can combine some of the aspects of document store via the json data types they added... of course I'm not really a DBA and don't have a lot of Mongo experience ... but personally I feel rdbms make more sense for growth/scaling..

meritt 9y ago
That's precisely why they IPO'd. Private investors needed an exit while they shift their money to Docker Inc for the next tech hype train. https://www.hntrends.com/2017/september.html?compare1=Mongodb&compare2=Docker&compare3=&compare4= https://www.hntrends.com/2017/september.html?compare1=Mongod...
bpicolo 9y ago
To be fair, Mongo is better than it's ever been. They even got through Jepsen just fine after wiredtiger. That said, it's pretty hard to make sense of when you would want non-relational dbms these days, especially in an era where you can get 100core systems in AWS/GCP. Write-scaling is still a pretty obvious reason, though things like Citus might help here.
- dsp1234 9y ago
  They even got through Jepsen just fine after wiredtiger. With non-default settings[0]. The Jepsen tests passed with the "linearizable" read concern. The default read concern is "local", which "Provides no guarantee that the data has been written to a majority of the replica set members (i.e. may be rolled back)."[1] This is like having "READ UNCOMMITTED" be the default read level in a traditional database system. The Jepsen tests passed with the "majority" write concern. The default write concern is "1", which means only the "primary" in a replica set needs to acknowledge the write[2]. This does not guarantee safety in the face of network partitions. It's still not safe out of the box. [0] - https://jepsen.io/analyses/mongodb-3-4-0-rc3 https://jepsen.io/analyses/mongodb-3-4-0-rc3 "With the v1 protocol, majority writes, and linearizable reads, MongoDB 3.4.1 (and the current development release, 3.5.1) pass all MongoDB Jepsen tests:" [1] - https://docs.mongodb.com/manual/reference/read-concern/ https://docs.mongodb.com/manual/reference/read-concern/ [2] - https://docs.mongodb.com/manual/reference/write-concern/ https://docs.mongodb.com/manual/reference/write-concern/
  - stingraycharles 9y ago
    These kind of default settings make sense, though. If you really care about lineair writes, you know how to configure it. Same goes for example for PostgreSQL [1], that uses Read Committed rather than Serializable transaction isolation by default because for the majority of the people, this is fine, and the performance tradeoffs are worth it. [1] https://www.postgresql.org/docs/9.5/static/transaction-iso.html https://www.postgresql.org/docs/9.5/static/transaction-iso.h...
    - bpicolo 9y ago
      Yeah, and you can turn off fsync in postgres if you want a blazing fast db that loses your data. :D
      - threeseed 9y ago
        This meme isn't even funny anymore. It was a bug that was fixed many, many years ago and was only true if you didn't use any client libraries.
  - threeseed 9y ago
    Not sure if you know much about databases but those are standard defaults. Cassandra as well doesn't require a full quorum to acknowledge writes. It just relies on the closest node. Likewise for Oracle. http://docs.datastax.com/en/archived/cassandra/2.0/cassandra/dml/dml_config_consistency_c.html http://docs.datastax.com/en/archived/cassandra/2.0/cassandra...
- growse 9y ago
  > That said, it's pretty hard to make sense of when you would want non-relational dbms these days. Write-scaling is still a pretty obvious reason, though things like Citus might help here. Personally, I find a non-relational database useful when my data model is non-relational.
  - bpicolo 9y ago
    Sure. The most direct argument against that is that Postgresql jsonb is just non-relational data support in a first class relational DB, which is pretty great, so to an extend you get the best of both worlds, though I'm sure you can find a case where it's not quite optimal vs some nosql db. This talk is a pretty nifty perf overview: https://www.percona.com/live/e17/sessions/high-performance-json-postgresql-vs-mongodb https://www.percona.com/live/e17/sessions/high-performance-j... That said, if you know beforehand that horizontal scaling will be a crucial factor, probably postgres isn't the first choice. But with how fast CPUs are these days it's usually not important for a long time.
    - jsjohnst 9y ago
      > But with how fast CPUs are these days it's usually not important for a long time. That’s a very naive statement to make.
      - bpicolo 9y ago
        Is it? Because there are a ton of companies out there running postgres, mysql and scaling workloads just fine.
        jsjohnst 9y ago
        I upvoted you because you’re technically right for many cases, but if you’d ever dealt with a database you couldn’t scale further (we were using multiple of the largest instances EC2 had at the time) and new data was flowing in faster than you could delete it and downtime wasn’t an option, you too would hate any predecessors who said “you can always scale higher” before things got so bad it was almost impossible to recover.
_jordan 9y ago
I sorta feel the same way - but then I think about the 800(?) employees they have and their combined skillset in database administration, internals, research, philosophy and I'm left feeling like there has got to be a very strong technical and business use case that I just don't see. Like I would imagine that if I were locked in a room with their Sr. product people and devs, they could easily convince most people of mongodb. I would pay money to see a debate style db-off between Postgres' core devs, and representatives from Mongodb.
VintageCool 9y ago
Mongo is no longer as "hip", but it is slowly breaking into the enterprise as people learn the right use cases for it.
- lotyrin 9y ago
  And as it matures to meet more cases (e.g. new consensus, storage solutions).
- takeda 9y ago
  I still have trouble to find proper use cases for MongoDB that a more solid database couldn't handle.
rhizome 9y ago
I had a phone screen with a company just a couple of months ago that ran on MongoDB and they were committed to it.
- deleted 9y ago
  [deleted]
- gaius 9y ago
  Sounds like you dodged a bullet!
da_chicken 9y ago
RDBMS makes sense for most applications. Most applications store data that can be fit to the relational model. Most applications aren't big data or data mining OLAP. Most RDBMSs can do key-value stores very well now. Most applications also care more about consistency over availability, which is what RDBMSs do (CAP theorem). Many NoSQL data stores choose availability and partitioning and sacrifice consistency (i.e., "eventual consistency"). There's a lot of applications that you can't sacrifice consistency for. Electronic health records, financial records, student records, employee records, etc. You care that the data are accurate and up to date, and you want the system to error if it can't provide that. Wrong answers and "close enough" answers aren't good enough. Now, if you're running Reddit or Wikipedia or Facebook or HN... do you really care if a user doesn't get the absolute latest version of a document or comment? No, not really. If the content is hours old it's a problem, but it's not a big deal if it's a few minutes out of date. You care more that your users get a version of the document more than you care that they get the latest version of the document.
- eternalban 9y ago
  > RDBMS makes sense for most applications. But "applications" are built by development teams. So: Does an "RDBMS makes sense for most applications"?
  - kornish 9y ago
    Could you point to a definition of "application" that has the word "team" in it?
    - eternalban 9y ago
      Why should I waste time on a non-sequitur?
- zzzcpan 9y ago
  You don't seem to know this, but no traditional RDBMSs actually provide CAP consistency, for that they would have to use at least two-phase commit or something, but they don't. So, they all are noCAP databases. Electronic health or financial records are way safer in a proper eventually consistent database, like orders of magnitude safer, but everyone just takes the risk with some insurance at best to cover the losses. EDIT: If you downvote, please explain why. You can't disagree with the truth.
stuffedBelly 9y ago
It's not hip anymore, but it's still relevant. A company might need to be hip to hype up their technology at the initial stage to gain audiences but eventually they need to settle on a mature business model that might not seem exciting but would let the company survive.
zzzcpan 9y ago
Postgres is actually much less solid, it's a database from the different era and doesn't come close to any post-CAP database, even to the infamous Mongodb.
- orf 9y ago
  yeah... no. Can you explain why being "from a different era" (and so having a hell of a lot more development time and battle testing) is a bad thing. While you're at it you could also elaborate on why Postgres is much less "solid" than a database that literally eats writes without any consensus as to if they are valid and/or actually written. After that you could explain why "post-cap" is a thing. Until you do, your comment is pretty useless and it sounds like you could do with a nice shot of consistent, well designed database right to the heart.
gordon_freeman 9y ago
whenever I hear people say such things as "Oh..this app won't work well with RDBMS and it definitely needs a Document style Db.", I recall that facebook from its beginning and still use MySQL (RDBMS) database. This proves that RDBMS is relentlessly scalable and can work with very complex apps.
- ryanianian 9y ago
  and facebook has had to spend millions in making it work for their use-cases. it's not like facebook just enables the --scale flag for vanilla mysql and then walks away. not saying they'd be able to make vanilla mongo scale to their needs without serious investment either, but saying "facebook uses this so therefore it's good enough for me" discounts a lot of work that goes into making those solutions work for their needs/scale.
mirekrusin 9y ago
This fact has not dribbled down from programmers to higher management yet, it seems.

meritt 9y ago

That's precisely why they IPO'd. Private investors needed an exit while they shift their money to Docker Inc for the next tech hype train. https://www.hntrends.com/2017/september.html?compare1=Mongodb&compare2=Docker&compare3=&compare4= https://www.hntrends.com/2017/september.html?compare1=Mongod...

bpicolo 9y ago

To be fair, Mongo is better than it's ever been. They even got through Jepsen just fine after wiredtiger. That said, it's pretty hard to make sense of when you would want non-relational dbms these days, especially in an era where you can get 100core systems in AWS/GCP. Write-scaling is still a pretty obvious reason, though things like Citus might help here.

dsp1234 9y ago
They even got through Jepsen just fine after wiredtiger. With non-default settings[0]. The Jepsen tests passed with the "linearizable" read concern. The default read concern is "local", which "Provides no guarantee that the data has been written to a majority of the replica set members (i.e. may be rolled back)."[1] This is like having "READ UNCOMMITTED" be the default read level in a traditional database system. The Jepsen tests passed with the "majority" write concern. The default write concern is "1", which means only the "primary" in a replica set needs to acknowledge the write[2]. This does not guarantee safety in the face of network partitions. It's still not safe out of the box. [0] - https://jepsen.io/analyses/mongodb-3-4-0-rc3 https://jepsen.io/analyses/mongodb-3-4-0-rc3 "With the v1 protocol, majority writes, and linearizable reads, MongoDB 3.4.1 (and the current development release, 3.5.1) pass all MongoDB Jepsen tests:" [1] - https://docs.mongodb.com/manual/reference/read-concern/ https://docs.mongodb.com/manual/reference/read-concern/ [2] - https://docs.mongodb.com/manual/reference/write-concern/ https://docs.mongodb.com/manual/reference/write-concern/
- stingraycharles 9y ago
  These kind of default settings make sense, though. If you really care about lineair writes, you know how to configure it. Same goes for example for PostgreSQL [1], that uses Read Committed rather than Serializable transaction isolation by default because for the majority of the people, this is fine, and the performance tradeoffs are worth it. [1] https://www.postgresql.org/docs/9.5/static/transaction-iso.html https://www.postgresql.org/docs/9.5/static/transaction-iso.h...
  - bpicolo 9y ago
    Yeah, and you can turn off fsync in postgres if you want a blazing fast db that loses your data. :D
    - threeseed 9y ago
      This meme isn't even funny anymore. It was a bug that was fixed many, many years ago and was only true if you didn't use any client libraries.
- threeseed 9y ago
  Not sure if you know much about databases but those are standard defaults. Cassandra as well doesn't require a full quorum to acknowledge writes. It just relies on the closest node. Likewise for Oracle. http://docs.datastax.com/en/archived/cassandra/2.0/cassandra/dml/dml_config_consistency_c.html http://docs.datastax.com/en/archived/cassandra/2.0/cassandra...
growse 9y ago
> That said, it's pretty hard to make sense of when you would want non-relational dbms these days. Write-scaling is still a pretty obvious reason, though things like Citus might help here. Personally, I find a non-relational database useful when my data model is non-relational.
- bpicolo 9y ago
  Sure. The most direct argument against that is that Postgresql jsonb is just non-relational data support in a first class relational DB, which is pretty great, so to an extend you get the best of both worlds, though I'm sure you can find a case where it's not quite optimal vs some nosql db. This talk is a pretty nifty perf overview: https://www.percona.com/live/e17/sessions/high-performance-json-postgresql-vs-mongodb https://www.percona.com/live/e17/sessions/high-performance-j... That said, if you know beforehand that horizontal scaling will be a crucial factor, probably postgres isn't the first choice. But with how fast CPUs are these days it's usually not important for a long time.
  - jsjohnst 9y ago
    > But with how fast CPUs are these days it's usually not important for a long time. That’s a very naive statement to make.
    - bpicolo 9y ago
      Is it? Because there are a ton of companies out there running postgres, mysql and scaling workloads just fine.
      - jsjohnst 9y ago
        I upvoted you because you’re technically right for many cases, but if you’d ever dealt with a database you couldn’t scale further (we were using multiple of the largest instances EC2 had at the time) and new data was flowing in faster than you could delete it and downtime wasn’t an option, you too would hate any predecessors who said “you can always scale higher” before things got so bad it was almost impossible to recover.

_jordan 9y ago

I sorta feel the same way - but then I think about the 800(?) employees they have and their combined skillset in database administration, internals, research, philosophy and I'm left feeling like there has got to be a very strong technical and business use case that I just don't see. Like I would imagine that if I were locked in a room with their Sr. product people and devs, they could easily convince most people of mongodb. I would pay money to see a debate style db-off between Postgres' core devs, and representatives from Mongodb.

VintageCool 9y ago

Mongo is no longer as "hip", but it is slowly breaking into the enterprise as people learn the right use cases for it.

lotyrin 9y ago
And as it matures to meet more cases (e.g. new consensus, storage solutions).
takeda 9y ago
I still have trouble to find proper use cases for MongoDB that a more solid database couldn't handle.

rhizome 9y ago

I had a phone screen with a company just a couple of months ago that ran on MongoDB and they were committed to it.

deleted 9y ago
[deleted]
gaius 9y ago
Sounds like you dodged a bullet!

da_chicken 9y ago

RDBMS makes sense for most applications. Most applications store data that can be fit to the relational model. Most applications aren't big data or data mining OLAP. Most RDBMSs can do key-value stores very well now. Most applications also care more about consistency over availability, which is what RDBMSs do (CAP theorem). Many NoSQL data stores choose availability and partitioning and sacrifice consistency (i.e., "eventual consistency"). There's a lot of applications that you can't sacrifice consistency for. Electronic health records, financial records, student records, employee records, etc. You care that the data are accurate and up to date, and you want the system to error if it can't provide that. Wrong answers and "close enough" answers aren't good enough. Now, if you're running Reddit or Wikipedia or Facebook or HN... do you really care if a user doesn't get the absolute latest version of a document or comment? No, not really. If the content is hours old it's a problem, but it's not a big deal if it's a few minutes out of date. You care more that your users get a version of the document more than you care that they get the latest version of the document.

eternalban 9y ago
> RDBMS makes sense for most applications. But "applications" are built by development teams. So: Does an "RDBMS makes sense for most applications"?
- kornish 9y ago
  Could you point to a definition of "application" that has the word "team" in it?
  - eternalban 9y ago
    Why should I waste time on a non-sequitur?
zzzcpan 9y ago
You don't seem to know this, but no traditional RDBMSs actually provide CAP consistency, for that they would have to use at least two-phase commit or something, but they don't. So, they all are noCAP databases. Electronic health or financial records are way safer in a proper eventually consistent database, like orders of magnitude safer, but everyone just takes the risk with some insurance at best to cover the losses. EDIT: If you downvote, please explain why. You can't disagree with the truth.

stuffedBelly 9y ago

It's not hip anymore, but it's still relevant. A company might need to be hip to hype up their technology at the initial stage to gain audiences but eventually they need to settle on a mature business model that might not seem exciting but would let the company survive.

zzzcpan 9y ago

Postgres is actually much less solid, it's a database from the different era and doesn't come close to any post-CAP database, even to the infamous Mongodb.

orf 9y ago
yeah... no. Can you explain why being "from a different era" (and so having a hell of a lot more development time and battle testing) is a bad thing. While you're at it you could also elaborate on why Postgres is much less "solid" than a database that literally eats writes without any consensus as to if they are valid and/or actually written. After that you could explain why "post-cap" is a thing. Until you do, your comment is pretty useless and it sounds like you could do with a nice shot of consistent, well designed database right to the heart.

gordon_freeman 9y ago

whenever I hear people say such things as "Oh..this app won't work well with RDBMS and it definitely needs a Document style Db.", I recall that facebook from its beginning and still use MySQL (RDBMS) database. This proves that RDBMS is relentlessly scalable and can work with very complex apps.

ryanianian 9y ago
and facebook has had to spend millions in making it work for their use-cases. it's not like facebook just enables the --scale flag for vanilla mysql and then walks away. not saying they'd be able to make vanilla mongo scale to their needs without serious investment either, but saying "facebook uses this so therefore it's good enough for me" discounts a lot of work that goes into making those solutions work for their needs/scale.

mirekrusin 9y ago

This fact has not dribbled down from programmers to higher management yet, it seems.