Comment by carlos-menezes

1 year ago

My take: the industry is so set on SQL as as standard that FQL made Fauna a hard sell for production applications. Also, the pricing was quite steep.

Even mongo only got a lot of people excited because they had hot girls on the stalls in the conferences. That i think was a master stroke in marketing to nerds. of course later on they improved the product as well, but initially it was a buggy mess and should not have survived the first few years.

  • The one constant in my career has been mongoDB -- specifically, projects to replace it with a relational database after a deployment had failed to deliver any of the expected benefits, and introduced unforeseen downsides that had become untenable. Mongo has literally never come up in any context for me where it wasn't either already, or eventually, slated for retirement.

    I absolutely don't doubt a document store including mongo is an ideal solution for certain specific applications. I just haven't come across one yet personally. For me personally, I would use Postgres for most things and JSONB columns for document-like things until I found a reason to change.

    • The reason to change is scale. If your Postgres spend is in the six digits a month range, JSONB is probably very painful for you. It does not perform very well. Additionally, you've probably spent a good amount of engineering time painstakingly sharding your database at the application level and hoping you've done it correctly. MongoDB solves these problems out of the box, among others. I have run both of these above 1M a month in spend and I would certainly choose MongoDB for this over Postgres. If you plan on never spending a lot on your database, I do like Postgres a lot, still.

      2 replies →

    • Everyone earns the scars from understanding that all data has a schema. If you use pg, you mostly resolve the schema on write; if you use mongodb, you resolve it into a schema on read as well. The latter turns out to be very hard to make robust.