6 ms·

Not the OP, but RethinkDB is superior in many ways including stability, integrity and the feature set for pretty much every use case you would consider using Mo

by ralfn 10y ago

Not the OP, but RethinkDB is superior in many ways including stability, integrity and the feature set for pretty much every use case you would consider using MongoDB. But with Jespen tests MongoDB can finally be considered a contender. Its not like competent teams were using it in production. Right?

hendzen 10y ago
Do you not consider Stripe to be a competent team? Please, name some F500 companies using RethinkDB to power critical infrastructure. There are many using MongoDB. While Rethink is widely renowned among the HN set it is nonexistent in comparison when looking at actual deployments. The reigning HN view of MongoDB being a buggy mess is outdated. Yes, they overmarketed a buggy project in 2009. It didn't matter, because they built a product that developers loved (and continue to love) to use. RethinkDB didn't aggressively market itself, and look where it is now - defunct. Mongo used that momentum to raise money and hire an incredible engineering team, including Keith Bostic, one of the fathers of Unix, and Michael Cahill, the inventor of the transaction isolation mechanism used in Postgres. Sometimes you need to employ aggressive business tactics to get to a point where you have the engineering resources to build a world class project. Moreso when you need to catch up to millions of man hours spent building Oracle and MSSQL.
- dijit 10y ago
  ah, the "x uses y so it must be good" fallacy I should note that I work for a multi-national gaming company and we use software that is ABSOLUTELY not fit for purpose, but once you have a hard dependency on something and the cost of muddling through is _less_ than the cost of a rewrite then you're going to be stuck supporting it. This is the reality of technology in enterprise.
  - hendzen 10y ago
    That specific point was in reply to the GP's statement that "competent teams" weren't using it in production.
    - lotyrin 10y ago
      I don't think it should be taken as given that there's a correlation between competency and the size of an organization that a team exists within, and I don't think such a correlation, when combined with large organizations' usage of MongoDB would challenge the assertion that there exists an anticorrelation between team competency and use of MongoDB. Looking at the numbers, larger organizations straight-forwardly seem like they should be more likely to eventually hire mediocre talent, survive despite having done so, and more likely to have adopted any given tool.
      - hendzen 10y ago
        You speak of "correlation" and "looking at the numbers" but provide no data. What exactly is your point?
        lotyrin 10y ago
        The point? How do you draw a line from "Fortune 500s use Mongo" to "Mongo is used by competent teams"? I specifically challenge that you can do so, given a model of a large organization as being necessarily more diverse (regressing to the mean of general competency, more likely to have facts like "org Y uses tech X" being true) and more robust to survive failures as it grows. We don't have data, but we can still model (if nothing else, to think about what data we would need).
      - geocar 10y ago
        I think you're looking at it wrong. It's not a popularity contest; I've seen billion dollar companies use fucking stupid tooling as well, but they still have the right processes where they don't lose data. Mongo, on the other hand, loses data.
        lotyrin 10y ago
        In non-tech centric large orgs, it seems you frequently do not have the talent required to be be both risk averse and productive at the same time, so "IT" becomes a risk averse and non-productive political structure from which springs an "alternative IT" rebellion group (if the initiative is lead from above) or many little cowboy teams (if the initiative is driven from below) and these will be "productive" at the expense of having no processes for avoiding stupid risks that, amongst other things, can lead to data loss.
- keithnz 10y ago
  as an aside, Stripe are putting money in to support RethinkDB
jasondc 10y ago
Lots of hyperbole in your statement. Indeed lists 6200 job listings for mongodb[1], 37 for rethinkdb[2]. [1] https://www.indeed.com/jobs?q=mongodb&l= https://www.indeed.com/jobs?q=mongodb&l= [2] https://www.indeed.com/jobs?q=rethinkdb&l= https://www.indeed.com/jobs?q=rethinkdb&l=
- josephg 10y ago
  Rethinkdb is still the new database on the block, and never really found it's feet. Look up Postgres, Cassandra, Kafka, Riak, MySQL/Mariadb or MSSQL. (Or dare I say it, oracle). All of those tools have a long history of reliability and solid engineering.
  - hendzen 10y ago
    Ha! MySQL having a long history of reliability... Son have you heard of MyISAM?
    - nurettin 10y ago
      Ah, early 2000s and the table level lock during inserts but lightning fast reads. Postgres was still a fledgling back then.
    - takeda 10y ago
      In many ways MySQL is similar to MongoDB. Both started out being written by people who know nothing about databases and both threw away years of database research. Both gained popularity due to being accepted choice by web-based languages (PHP vs NodeJS) Both were faster than more established competition, only to turn out that both were losing data. Both turned out to be designed fundamentally wrong and had a replacement engines that are more reliable (ISAM/MyISAM vs InnoDB and v0 vs v1). Both still have quirks due to bad decisions in the past, but which can't be easilly fixed due to breaking compatibility.
      - hendzen 10y ago
        You're comparing ISAM/MySAM (storage engine) to the MongoDB replication protocol. As a more relevant parallel MongoDB also replaced its original storage engine with one acquired from WiredTiger (BerkeleyDB founders). One big difference from a corporate strategy perspective is that MySQL let the replacement storage engine (InnoDB) fall in to the hands of Oracle. MongoDB was smart enough to make sure that they were the acquirer, which puts them in control of their own destiny. If MongoDB is heading along the path of MySQL, that's a pretty good path to be on considering that MySQL is used as the store of record at Facebook, Twitter and some parts of Google.
k33n 10y ago
> Its not like competent teams were using it in production. Right? I've heard that about 1000 times a day for 6 years. Usually the person stating it is snickering as if they are clued into some unknown secret. Mongo does work in production at many shops, and in many forms. Sometimes it's used as the main database, sometimes it's used to house specific slices of data, etc.
- vacri 10y ago
  As a sysadmin, I got tired of the devs constantly ragging on Mongodb (the same folks that selected it before I was hired). I eventually got fed up and said: "why do we use it if you all hate it so much. Let's replace it. What do you want to use instead, it's easy for me to set up something new". Cue everyone going "ah, it's not so bad, really..." MongoDB is the Nickelback of databases: a reasonable act that's not going to blow your socks off, but one where saying "OMG I hate it!" somehow signals membership to some cool clique of connoisseurs.
  - x0x0 10y ago
    Well, I'm a member of the MongoDB is worth quitting over club. I replaced it at a former employer with postgres. Eng waved bye to an endless stream of operational issues, and customers saw better uptimes and much much faster responses.
    - navalsaini 10y ago
      When was that and which version of mongodb? Do you suppose things have improved after 3.0 etc.
  - jgord 10y ago
    alternative anecdota : I rewrote a backend that was using mongo, moved it to postgresql+postgis. Solved an ever-expanding RAM issue and is still blindingly fast [ on SSD hosting ] The main win was not server stability, it was having general tools to manage data .. including the inbuilt geo-algorithms that come with postGIS. eg. I could make our data set 9x smaller by smoothing map paths. I still love the Mongo api, but I just cant risk it with data on projects that people are paying for, or that I need to support. [ I think the real sweet spot will be deep integration of javascript and json into postgres - so I can write stored procs in js, get db events in js, wrangle json fluidly.. all of which is improving. ]

by ralfn 10y ago

hendzen 10y ago

Do you not consider Stripe to be a competent team? Please, name some F500 companies using RethinkDB to power critical infrastructure. There are many using MongoDB. While Rethink is widely renowned among the HN set it is nonexistent in comparison when looking at actual deployments. The reigning HN view of MongoDB being a buggy mess is outdated. Yes, they overmarketed a buggy project in 2009. It didn't matter, because they built a product that developers loved (and continue to love) to use. RethinkDB didn't aggressively market itself, and look where it is now - defunct. Mongo used that momentum to raise money and hire an incredible engineering team, including Keith Bostic, one of the fathers of Unix, and Michael Cahill, the inventor of the transaction isolation mechanism used in Postgres. Sometimes you need to employ aggressive business tactics to get to a point where you have the engineering resources to build a world class project. Moreso when you need to catch up to millions of man hours spent building Oracle and MSSQL.

dijit 10y ago
ah, the "x uses y so it must be good" fallacy I should note that I work for a multi-national gaming company and we use software that is ABSOLUTELY not fit for purpose, but once you have a hard dependency on something and the cost of muddling through is _less_ than the cost of a rewrite then you're going to be stuck supporting it. This is the reality of technology in enterprise.
- hendzen 10y ago
  That specific point was in reply to the GP's statement that "competent teams" weren't using it in production.
  - lotyrin 10y ago
    I don't think it should be taken as given that there's a correlation between competency and the size of an organization that a team exists within, and I don't think such a correlation, when combined with large organizations' usage of MongoDB would challenge the assertion that there exists an anticorrelation between team competency and use of MongoDB. Looking at the numbers, larger organizations straight-forwardly seem like they should be more likely to eventually hire mediocre talent, survive despite having done so, and more likely to have adopted any given tool.
    - hendzen 10y ago
      You speak of "correlation" and "looking at the numbers" but provide no data. What exactly is your point?
      - lotyrin 10y ago
        The point? How do you draw a line from "Fortune 500s use Mongo" to "Mongo is used by competent teams"? I specifically challenge that you can do so, given a model of a large organization as being necessarily more diverse (regressing to the mean of general competency, more likely to have facts like "org Y uses tech X" being true) and more robust to survive failures as it grows. We don't have data, but we can still model (if nothing else, to think about what data we would need).
    - geocar 10y ago
      I think you're looking at it wrong. It's not a popularity contest; I've seen billion dollar companies use fucking stupid tooling as well, but they still have the right processes where they don't lose data. Mongo, on the other hand, loses data.
      - lotyrin 10y ago
        In non-tech centric large orgs, it seems you frequently do not have the talent required to be be both risk averse and productive at the same time, so "IT" becomes a risk averse and non-productive political structure from which springs an "alternative IT" rebellion group (if the initiative is lead from above) or many little cowboy teams (if the initiative is driven from below) and these will be "productive" at the expense of having no processes for avoiding stupid risks that, amongst other things, can lead to data loss.
keithnz 10y ago
as an aside, Stripe are putting money in to support RethinkDB

jasondc 10y ago

Lots of hyperbole in your statement. Indeed lists 6200 job listings for mongodb[1], 37 for rethinkdb[2]. [1] https://www.indeed.com/jobs?q=mongodb&l= https://www.indeed.com/jobs?q=mongodb&l= [2] https://www.indeed.com/jobs?q=rethinkdb&l= https://www.indeed.com/jobs?q=rethinkdb&l=

josephg 10y ago
Rethinkdb is still the new database on the block, and never really found it's feet. Look up Postgres, Cassandra, Kafka, Riak, MySQL/Mariadb or MSSQL. (Or dare I say it, oracle). All of those tools have a long history of reliability and solid engineering.
- hendzen 10y ago
  Ha! MySQL having a long history of reliability... Son have you heard of MyISAM?
  - nurettin 10y ago
    Ah, early 2000s and the table level lock during inserts but lightning fast reads. Postgres was still a fledgling back then.
  - takeda 10y ago
    In many ways MySQL is similar to MongoDB. Both started out being written by people who know nothing about databases and both threw away years of database research. Both gained popularity due to being accepted choice by web-based languages (PHP vs NodeJS) Both were faster than more established competition, only to turn out that both were losing data. Both turned out to be designed fundamentally wrong and had a replacement engines that are more reliable (ISAM/MyISAM vs InnoDB and v0 vs v1). Both still have quirks due to bad decisions in the past, but which can't be easilly fixed due to breaking compatibility.
    - hendzen 10y ago
      You're comparing ISAM/MySAM (storage engine) to the MongoDB replication protocol. As a more relevant parallel MongoDB also replaced its original storage engine with one acquired from WiredTiger (BerkeleyDB founders). One big difference from a corporate strategy perspective is that MySQL let the replacement storage engine (InnoDB) fall in to the hands of Oracle. MongoDB was smart enough to make sure that they were the acquirer, which puts them in control of their own destiny. If MongoDB is heading along the path of MySQL, that's a pretty good path to be on considering that MySQL is used as the store of record at Facebook, Twitter and some parts of Google.

k33n 10y ago

> Its not like competent teams were using it in production. Right? I've heard that about 1000 times a day for 6 years. Usually the person stating it is snickering as if they are clued into some unknown secret. Mongo does work in production at many shops, and in many forms. Sometimes it's used as the main database, sometimes it's used to house specific slices of data, etc.

vacri 10y ago
As a sysadmin, I got tired of the devs constantly ragging on Mongodb (the same folks that selected it before I was hired). I eventually got fed up and said: "why do we use it if you all hate it so much. Let's replace it. What do you want to use instead, it's easy for me to set up something new". Cue everyone going "ah, it's not so bad, really..." MongoDB is the Nickelback of databases: a reasonable act that's not going to blow your socks off, but one where saying "OMG I hate it!" somehow signals membership to some cool clique of connoisseurs.
- x0x0 10y ago
  Well, I'm a member of the MongoDB is worth quitting over club. I replaced it at a former employer with postgres. Eng waved bye to an endless stream of operational issues, and customers saw better uptimes and much much faster responses.
  - navalsaini 10y ago
    When was that and which version of mongodb? Do you suppose things have improved after 3.0 etc.
- jgord 10y ago
  alternative anecdota : I rewrote a backend that was using mongo, moved it to postgresql+postgis. Solved an ever-expanding RAM issue and is still blindingly fast [ on SSD hosting ] The main win was not server stability, it was having general tools to manage data .. including the inbuilt geo-algorithms that come with postGIS. eg. I could make our data set 9x smaller by smoothing map paths. I still love the Mongo api, but I just cant risk it with data on projects that people are paying for, or that I need to support. [ I think the real sweet spot will be deep integration of javascript and json into postgres - so I can write stored procs in js, get db events in js, wrangle json fluidly.. all of which is improving. ]