4 ms·

I had a small business depending on the Etsy API during the time they transitioned some storage to Mongo. The immediate effect for us was a downturn in function

I had a small business depending on the Etsy API during the time they transitioned some storage to Mongo. The immediate effect for us was a downturn in functionality and reliability with no apparent advantages. In the midst of other serious concerns about their direction, we questioned why Etsy was doing this on the API mailing list and were told basically we didn't know what we were talking about and it wasn't out business. Fair enough, sort of. It was a hot time for NoSQL and document DBs. Having investigated using Mongo myself to little avail, I asked why they didn't just use Postgres. If I recall correctly, a couple years later they published a Mongo at Etsy postmortem which concluded they should have just stayed with Postgres.

b0afc375b5 6y ago
For anyone else curious, I found the postmortem here: https://mcfunley.com/why-mongodb-never-worked-out-at-etsy https://mcfunley.com/why-mongodb-never-worked-out-at-etsy Which was compiled here: https://github.com/icy/w2w https://github.com/icy/w2w
- Kwantuum 6y ago
  That repo is interesting. A quick ctrl+F seems to indicate that pretty much every instance of "MongoDB" is "Moving from Mongo to Postrges or DynamoDB" (there is one single entry of moving to Mongo from MySQL). Almost as if Mongo is just not a good database (or people are too eager to use it for things which it does not do well).
  - gravypod 6y ago
    Making efficient use if mongodb is very difficult but if you build your app and expectations correctly you can get something very performant. For example pre-4.x listing huge collections was unexpectedly extremely slow.
    - chrisco255 6y ago
      Yeah Mongo is 10 years old or so at this point. This article was written in 2015 about decisions made years earlier. It's now reached maturity and stability. It's now "boring tech".
      - Yeroc 6y ago
        Um, even if it's mature technology that doesn't negate the costs of operating two different databases which is a large part of what the original presentation is about.
      - rvba 6y ago
        Does mongoDB still use math.random to select 10% of errors and only report them, while 90% are ignored? Or did they correct this "behavior"?
        reasonabl_human 6y ago
        Huh? That sounds like crazy talk..
      - arcturus17 6y ago
        It may be more established but it suffers from a similar problem: some people continue choosing it for the wrong reasons, such as "our backend is in JS, most of our devs only know JS, and it's easy to just dump objects in there", which is an abhorrent reason for choosing it, and will end up biting you. IMO this would be a case where if you're dealing with a relational domain and the engineers really don't know SQL you should either (a) rethink your hiring policy or (b) spend one of your innovation tokens in having everyone learn SQL. (I have to add the inevitable disclaimer that I actually love JS and do not want my words to be misinterpreted as a cheap dig at it)
collyw 6y ago
I am left maintaining a mongo db from 7 years ago or so, when NoSQL was peak hype cycle. Like you say it´s crap.
- NomDePlum 6y ago
  Lots of good reasons to use NoSQL. All pretty much hang off what sort of data access pattern you need. If you have an application that retrieves an works on a top level entity then NoSQL fits very nicely. When you have a dataset that is shared and aggregate information is needed not so much and you are likely better of considering a SQL database of some sort.
  - bitwize 6y ago
    > When you have a dataset that is shared and aggregate information is needed not so much and you are likely better of considering a SQL database of some sort. There are best practices for this. Simply create a microservice per table, and then create a microservice that acts as a client to the other services and aggregates or joins the data from those services. No, I'm not kidding. This is literally what people do and recommend.
    - c-cube 6y ago
      And remember to implement distributed 2 phase commit to guarantee consistency! So much simpler than using old crufty sql
      - bitwize 6y ago
        Oh, pish and tosh! That's too much engineering! Instead, handwave about "eventual consistency" and save millions in infrastructure costs! Totally worth it for the benefits of being truly abstracted from your data storage layer. Because, you know, people change their database back ends more often than they change their sheets.
    - cosmodisk 6y ago
      Is this a joke or people seriously do this?

b0afc375b5 6y ago

For anyone else curious, I found the postmortem here: https://mcfunley.com/why-mongodb-never-worked-out-at-etsy https://mcfunley.com/why-mongodb-never-worked-out-at-etsy Which was compiled here: https://github.com/icy/w2w https://github.com/icy/w2w

Kwantuum 6y ago
That repo is interesting. A quick ctrl+F seems to indicate that pretty much every instance of "MongoDB" is "Moving from Mongo to Postrges or DynamoDB" (there is one single entry of moving to Mongo from MySQL). Almost as if Mongo is just not a good database (or people are too eager to use it for things which it does not do well).
- gravypod 6y ago
  Making efficient use if mongodb is very difficult but if you build your app and expectations correctly you can get something very performant. For example pre-4.x listing huge collections was unexpectedly extremely slow.
  - chrisco255 6y ago
    Yeah Mongo is 10 years old or so at this point. This article was written in 2015 about decisions made years earlier. It's now reached maturity and stability. It's now "boring tech".
    - Yeroc 6y ago
      Um, even if it's mature technology that doesn't negate the costs of operating two different databases which is a large part of what the original presentation is about.
    - rvba 6y ago
      Does mongoDB still use math.random to select 10% of errors and only report them, while 90% are ignored? Or did they correct this "behavior"?
      - reasonabl_human 6y ago
        Huh? That sounds like crazy talk..
    - arcturus17 6y ago
      It may be more established but it suffers from a similar problem: some people continue choosing it for the wrong reasons, such as "our backend is in JS, most of our devs only know JS, and it's easy to just dump objects in there", which is an abhorrent reason for choosing it, and will end up biting you. IMO this would be a case where if you're dealing with a relational domain and the engineers really don't know SQL you should either (a) rethink your hiring policy or (b) spend one of your innovation tokens in having everyone learn SQL. (I have to add the inevitable disclaimer that I actually love JS and do not want my words to be misinterpreted as a cheap dig at it)

collyw 6y ago

I am left maintaining a mongo db from 7 years ago or so, when NoSQL was peak hype cycle. Like you say it´s crap.

NomDePlum 6y ago
Lots of good reasons to use NoSQL. All pretty much hang off what sort of data access pattern you need. If you have an application that retrieves an works on a top level entity then NoSQL fits very nicely. When you have a dataset that is shared and aggregate information is needed not so much and you are likely better of considering a SQL database of some sort.
- bitwize 6y ago
  > When you have a dataset that is shared and aggregate information is needed not so much and you are likely better of considering a SQL database of some sort. There are best practices for this. Simply create a microservice per table, and then create a microservice that acts as a client to the other services and aggregates or joins the data from those services. No, I'm not kidding. This is literally what people do and recommend.
  - c-cube 6y ago
    And remember to implement distributed 2 phase commit to guarantee consistency! So much simpler than using old crufty sql
    - bitwize 6y ago
      Oh, pish and tosh! That's too much engineering! Instead, handwave about "eventual consistency" and save millions in infrastructure costs! Totally worth it for the benefits of being truly abstracted from your data storage layer. Because, you know, people change their database back ends more often than they change their sheets.
  - cosmodisk 6y ago
    Is this a joke or people seriously do this?