Hacker News Reader

Comment by thiscatis | Hacker News Reader

Would love to see an overview of companies that fell into the mongoDB trap and have / are migrating to another DB store.

View on HN

I inherited a MongoDB Ruby (Mongoid) stack that was a terrible choice for the data stored (i.e. relational data). Actually, I'm not really sure why Mongoid exists at all.

After several years of pain e.g. cursor timeouts (even when supposedly disabled), iterating over the same document multiple times in the one query etc. and of course no transactions (since added). I eventually migrated to PSQL (using some custom scripts) and everything is so much easier to maintain, much more stable and much faster.

We're still using MongoDB for our analytics though, as it's inherently unstructured non-relational data, so MongoDB does actually do an okay job. Well, except for the run away memory usage which leads to k8s killing the DB server for violating memory constraints every so often. Yes, MongoDB itself is configured with memory constraints, it seems WiredTiger ignores them.

Licensing was considered, however honestly MongoDB itself is (or at least was) so bad that licensing wasn't the primary motivating factor.

EDIT: Just to clarify, most of our data is relational, however we do have some unstructured data in PSQL stored in JSONB columns. They work a treat and in some cases have complex indexes on them - they far out-perform anything MongoDB was able to offer us.

What is the point of running containerized DB server in production? Isn't it an anti-pattern?

I wouldn't go as far as saying it's an anti-pattern. However, doing it properly is extremely difficult.

Why do we do it? Cost saving. It's that simple. For your information, I wouldn't say we do it "properly" either. We do a decent job though.

Basically, for us (and many other businesses) DBs are not the bottle-neck. Our business model facilitates a heap of static content that's served (via a CDN) without even hitting the DB. When the DB is used, it's 99% read-only; except for the analytics which aren't business critical.

As with all things, it's a trade-off.

Sounds not that cost-saving for me when you mention that your not critical DB OOM-crashes here and there. How much do you saving, like $150/year on dedicated host?

You're assuming that I'm just talking about hosting costs. I'm not.

Maintaining VPS infrastructure just to run a DB is a huge amount of overhead. More so, when the DB crashes and/or wildly consumes memory. You need disk/memory monitoring, logging, process monitoring, availability monitoring etc. What if the VPS itself goes down? What automated system is going to spin it back up?

A self-managed VPS DIY solution is substantially more expensive to maintain than using well-established tooling like k8s. These are all already solved problems. Not just that, it's a standardised work-flow with the rest of our infrastructure i.e. no manual futzing around with VPC etc. to get our cluster and externally managed VPS talking to each other.

For us, a DIY solution was never even on the cards. It was either a fully managed service or what we have now.

However, fully managed services don't just cost more per month. There's frequently additional development overhead, as the offerings are "off the shelf" software and not necessarily easily customised. For example, right now our PSQL deployment is running a custom PSQL extension that seamlessly handles BSON (MongoDB) Object IDs, semantically converting them to UUIDs. Thus, post-migration from MongoDB, application code isn't riddled with code handling legacy IDs.

Monthly service provider fees are but one consideration when performing costings.

EDIT: It's probably also worth noting that our entire infrastructure, including DBs, can be spun up as a k8s cluster on a developer's work machine in one command. We of course also have a staging environment, which mimics production. Development also ought to mimic production as closely as possible (but still be debuggable).

actually it works quite well when done correctly. basically k8s is less of an container solution and more like a "scheduling" solution. so it's actually way less painfull than setting up your own db.

That’s usually a sign that there is no Ops on staff to prevent the Devs from doing it, yes.

What you do mean by the "mongoDB trap"?

Are you saying companies are hurt by the license, or are you saying companies are hurt by software's behavior (e.g. consistency model)?

A lot of companies got lured into using mongodb because it was so developer friendly. It cost nothing and it was easy bring in the back door and alleviated the need for thought.

Then their sales people started coming around and asking for insane sums of money (like $10,000 per instance per year plus 100% markup on hardware to run in AWS - support is extra). They were worried about amazon and others offering a better so next they changed the license.

If it had been SQL it would have been easy to drop in another database. But Mongodb is so different from anything else that you need a major rewrite to get away from it. Postgres has some similiar functionality but it’s not drop in. Amazon has a more or less public beta of DocumentDB which as far as I can tell is a mongodb compatible interface to aurora backend - it works but doesn’t have the polish of RDS yet.

But Mongodb is so different from anything else that you need a major rewrite to get away from it.

Well actually....

One corner case. If you are using Mongo with the Mongo Linq driver in C#, you can switch it out for an RDMS without changing too much code with just a little foresight.

So why not just use a RDMS from day one?

Because we had data that fit better in a non relational store. We stored data that created from user generated forms and we loaded data back into those forms.

Why use a relational store? If you’re working with a system that will only be read and written by an object based language? Why keep converting back and forth between a relational model and an object oriented model?

In C#

  var seniorMales = from c in context.Customers 
  where c.Age > 65 && c.Sex == “M”

Would be translated at runtime to either MongoQuery, Sql, a foreach loop, etc depending on what “context” represented.

You get autocomplete and compile time checks.

When you want to add an record to your Mongo collection, you work with strongly typed

  IMongoCollection<Customer>

And the compiler will ensure that your collection stays consistent.

That doesn't make sense - how are you eventually moving to a RDBMS if your data is not suited to it?

What do you mean how?

Anything that you can store in object database you can normalize and store in an RDMS. ORMs have been translating relational models back and forth to object models for decades.

In the case of Mongo, you just create one object containing other objects, lists, arrays etc and the driver serializes it to a JSON like structure and stores it as is in the collection.

In the case of an RDMS, you create your C# classes to model your tables and relationships.

The driver translates the LINQ to the appropriate query language.

> Why use a relational store? If you’re working with a system that will only be read and written by an object based language? Why keep converting back and forth between a relational model and an object oriented model?

Well I can't tell you what the right choice in your system is, but in the general case I think going with a relational model by default generally makes sense because it's rather future proof. By that I mean a relational model gives you the most flexibility in the future to evolve your system in ways you couldn't/didn't anticipate when the system was initially designed.

If your data store is behind an API you modify the API. You’re often using a different database for your OLAP and OLTP anyway.

I think you got it backwards. A relational schema change is required and probably a data reindex or reload when you change a data model so relational is the least flexible as opposed to something like Mongo nosql?

If you’re just talking about storing and retrieving documents in a hierarchy with a semi-fixed format then aren’t you asking for a filesystem?

How do you propose that you query a filesystem? In this context, we are referring to a “document” as a structured JSON document. You still have a semi known structure with fields that you can index and query.

A schema change can handle changes needed to existing data, if you don't do that then sure Mongo is easier, but then you've broken data in your system.

I worked on a project with similar requirements. I just serialized the data with protobufs, encrypted it, and stashed it in S3. It was sensitive data so this also had the advantage of being easy to secure and audit.

No point using a relational db for that kind of thing.

And then when you need to do reports on the data and query it?

Why not just use Postgres, set a field as jsonb, done?

Why use Postgres just to store JSON? The entire tooling around Mongo is better for JSON Data.

Not to mention the LINQ driver....

And you can’t do updates on individual JSON fields in Postgres.

Yes you can - this is an article crated in 2017 https://www.idalko.com/crud-operations-postgres-jsonb/

From the article,

The problematic part with PostgresSQL JSONB is modifying a JSONB column content. In any case, we totally replace the old content by a new one. So, the update operations turn to the complex queries that can lose the content. You can avoid this by performing the full JSON reorganization before the persistent operation.

You still don’t have the richness of MongoQuery and the aggregation framework and the tooling around working with JSON data isn’t there. Let alone the native driver support.

Postgres is better than Mongo for all of Mongo’s use cases, and 100 others besides, why wouldn’t you use it?

Including the Mongo aggregation framework, tooling, driver support, in the case I mentioned LINQ support, various reporting packages, etc?

Due to the sensitive nature of the data and the need to keep it encrypted, breaking it down by columns into a schema we could query was a non goal.

A lot of people have difficulty trying to organize complex hierarchical data into rows and columns. A lot of places make you go through a dba to create or change a database which rubs power users the wrong way - and admittedly most of the dbas I’ve worked with are a lot more concerned with making backups fast then in your applications performance. Mongodb doesn’t make you do any of that. It doesn’t make you have authentication either. I think that’s a big reason why it got so popular.

Database versioning and migrations are a pain. I’ve tried both home grown and commercial database systems to make database changes part of the CI/CD process. I haven’t found one that I liked.

When I did implement a system with C#/Mongo, I fell in love with changing my database schema just by changing my C# objects. With the C# driver you can include a Dictionary as part of your object to round trip unmapped fields.

Not to mention that after you go through all of your modeling and figuring out your aggregate roots, you can just store the entire object graph with one .Add and the entire object is stored atomically without having to worry about transactions, table locks, etc.

Unlike with an RDMS where your beautiful aggregate root has to constantly be composed and decomposed.

I think it’s funny that web devs pretty much abandoned hierarchical databases since they are the OG database style.

I think it’s just going to take somebody shaking the cobwebs off of their X.500 manuals and making the query syntax and schemas a little more ergonomic for them to come back en vogue.

It’s one thing to have the ability to mold your DB to model hierarchical data but have your DB engine support it non-awkwardly might be a game changer. People are already used to apps needing a DB, cache, queues, S3, filesystem, service discovery, that adding one more thing would hardly break the bank.

Also Foundation DB supports mongodb clients. It also powers iMessage.

Maybe I'm misunderstanding, but I thought the new license is just about offering MongoDB as a service by itself. But if you're making any other sort of website and use MongoDB as a database, you can still install it and use it for free.

If the companies got lured into using MongoDB as a service, then I understand that prices could increase and companies could be in a pickle. But if companies got lured into using MongoDB as software, I don't see how they could have a problem.

You're correct, the new license only prevents AWS and other cloud from running the MongoDB software itself as a managed service unless they open-source their entire platform (although, as we see with DocumentDB, they can legally implement the API without the license coming into effect).

The parent comment states "their sales people started coming around and asking for insane sums of money" but I can't find any reference to this.

This was my understanding of the license as well. I read through the block and it very clearly suggested only selling the database as a service was not okay. Using the database as a data store should be fine.

If MongoDB really is sending salespeople to make claims against companies who they convinced to use their OSS database as a data-store, than they are indeed abusing their license and no one should use their database or support their company.

From what I read of the license, that shouldn't be the case though.

The fact that mongo was willing to screw over one set of users makes me worry they'd be willing to screw over all their users. It's a risk I wouldn't take, especially when there are so many other (arguably better) options out there.

I wouldn't choose mongo for many reasons, but this licensing change isn't one of them. It's in line with the general spirit of the GPL: if you're going to stand on the shoulders of giants, you should allow others to stand on your shoulders.

The only major change to the license is in adapting to the rise of cloud services.

The GPL is only a copyright license. The GPL DOES NOT impose restrictions on usage, where "usage" vs "distribution" gets defined by copyright law itself.

That's one of GPL's biggest strengths.

Also successful software packages that are GPL are GPL for everyone. You don't have a mother company that can bypass the GPL due to them owning the copyright. And when you do it's usually a scam that people can smell.

You can't say about a license change that it is in the "spirit of GPL" when the mother company, MongoDB Inc, doesn't have to play by the same rules as everyone else.

So I'm sorry, but when you're talking about the "spirit of GPL", you don't know what you're talking about.

https://www.mongodb.com/licensing/server-side-public-license...

The FAQ for the license change very clearly indicates that your reading is what was intended. Question #4 particularly contains the complete text of the section that was altered, and it's hard to see how they could have left themselves any room to penalize regular users.

  > If it had been SQL it would have been easy to drop in another database.

Not true at all. Way too many organisations are locked into Oracle just because it's too hard to switch to something cheaper.

Why is this? If Oracle uses SQL why can you not just export the database, make some transformations, and import it into a PostgreSQL db for example?

Because Oracle uses Oracle's flavour of SQL, and no two databases are feature compatible.

If you are correct then your consultancy can stand to make hundreds of millions and save companies billions on their Oracle instances!

More likely, though, is that Oracle users use Oracle-specific flavors of SQL in lots of legacy apps that no one wants to touch, and rely on the support contracts for continued assistance in keeping the database performant for its query load.

I feel like you’re imagining that SQL is more of a standard interface than it actually is. No two relational databases are quite the same and you’ll be stuck combing through your entire app looking for obscure syntax usage that depends on Oracle specific extensions or quirks.

There’s no incentive to not extend or try to improve SQL semantics because for proprietary databases it increases lock-in which is good for sales and for OSS databases the extensions are genuinely positive and increase developer productivity and you don’t feel bad about locking your users in because it’s OSS.

I think it is probably easier to port from one SQL dialect to another, than from Mongo’s hokey JSON based query language to anything else.

Also not easy.

We tried to do a migration from Sql Server to Postgres.

Even went as far as building a parser/compiler to transform Sql. Certain things are just too difficult to handle.

1. Sql Server supports arbitrary sql statements in queries. Postgres does not.

2. Data types are not the same.

3. Feature sets at the 'interface edge' between the client library and the engine differ. For example, Sql Server queries can return an arbitrary number of results.

It's true that Mongo uses a custom language, but with Mongo - you are unlikely to have any significant business logic in your data layer.

Also their API surface is relatively simple.

For example, FoundationDB has a layer that mimics the Mongo API. Amazon has one as well.

Including Amazon, until recently.

Well there is pl/sql for instance that oracle has, migration costs would be too high for most people. We use pl/sql extensively at work, I cannot even imagine the effort(time/money/people) it would take to migrate from oracle.

Relational/SQL databases still follow the same fundamental data model and query language, despite the differences in SQL syntax. I will argue migration is still easier. Just avoid stored procedures which complex logic, since these are essentially proprietary programming languages.

Even without stored procedures, its not easy.

To really take advantage of a database engine, you will probably end up using engine-specific idioms.

Postgres and Sql Server support recursive CTEs. MySql probably doesn't?

Sql Server supports cursors but is dog slow and generally not recommended for any sort of large scale operations.

Isolation levels and locking are really important as well. Do all engines even support the same isolation levels?

> Mongodb is so different from anything else

CouchDB is quietly weeping in a corner.

>If it had been SQL it would have been easy to drop in another database.

Hahaha. No.

If anything, migrating from something like Mongo might possibly be easier. Because it's non-relational, you probably have very little business logic in your database layer.

Unlike with Sql.

And even though Sql has a standard syntax, beyond vanilla CRUD queries, there are many differences. Even if 2 engines support the same synatx, the idiomatic way of doing something will differ.

(For example, cursors in Sql Server is extremely slow, whereas its a perfectly acceptable way of doing list operations in Postgres)

I used to build drivers for MongoDB because it was so easy.

MongoDB had a good run, I enjoyed it before migrating away. This license definitely hurts companies.

What to? I built my own Open Source solution (MIT/Zlib/Apache2).

Around same time Firebase was getting popular, and Graph databases were the way forward.

Combined them all together, now have Internet Archive and HackerNoon running it (https://github.com/amark/gun) in production!

I believe I saw you present at UtahJS a few years back. I was very impressed with your presentation about JavaScript performance. I think think about that talk every once in a while.

Thanks! I appreciate that :) JavaScript is not easy to get it to perform! :P

Link to tech talk for others: https://www.youtube.com/watch?v=BEqH-oZ4UXI

So you're saying MongoDB is good software, but not quite as good as yours. And you're saying the license is bad. Did you migrate away before or after the license change?

Could you elaborate on how companies are hurt by the license?

Wow, awesome work. I can't believe I haven't heard of gun before now. I'm off to play!

Why can't it be both?

I guess it could be both, but I consider them to be two completely separate issues, and referring to them together as "the mongoDB trap" without any further clarification is quite confusing to me. It could easily lead to misunderstanding, and people "answering" the question with only partial answers.

Additionally I'm curious how the license is harming companies, as I mentioned in this comment: https://news.ycombinator.com/item?id=20862996

The company made a terrible product so it is no surprise if they are a terrible company too. That's the trap: using a terrible product made by a terrible company.

I am neither for MongoDB or for any famous ABC or XYZ DB. But before I make my decision to change to any other DB, i evaluate my using my own conscience and not depend upon bashing of any X DB on the internet.

I had the opportunity to redesign the architectures of few productions running apps because of this superstition "Companies are falling due to MongoDB, lets switch to another DB"

Every single time, as an architect I have found that developers are just being fancy about their first-hand experience with some other database and they are unable to think in new direction which MongoDB is built for.

Following are the things most people miss:

1. MongoDB is not safe/secure. Anyone can hack it -> the default configuration were not optimized in previous MongoDB version but it doesn't mean it lacked User security API.

2. MongoDB does not support JOINs or query API just sucks -> No, it doesn't. First, You need to learn about denormalization and schema handling. Second, MongoDB supports JOIN semantics such as $lookup & $graphLookup. Third, it supports ElasticSearch like text searching capabilities and scoring. Fourth, it supports data aggregation pipelines with various ways to compose the data transforming operations including above 2.

3. It does not have triggers like RDBMS -> It has "change streams" which is more flexible than Trigger. This feature also enables multiple application servers in microservice architecture to use MongoDB as a central store. Want a custom ETL streaming pipeline? You got it.

4. It does not scale like ABC or XYZ DB -> Again understand point #2. Also, look into docs how distributed sharding works across replica sets. Spend some quality time figuring out what should be the KeyField to be used for distributed sharding of Data.

5. Licencing sucks -> Have you understood the whole project cost and complexity ? Have you actually looked at all the terms and conditions or are you just a big fan of OSS and for that you can support any stupid alternative?

As someone with several years of experience with both RDBs and mongodb, I totally agree with everything you said.

Also, you got downvoted by the same people that upvoted the stackoverflow post on the problems of downvoting on technical problems on the internet.

People might not like or know the technology and are guided by older tech gurus from the previous generation such as Edgar Frank "Ted" Codd, although he was a genius, now the market is much larger and there's a lot more use cases.

Additionally, most people know RDBs such as mysql and that's what they are comfortable with, i.e. can't get out of their comfort zone and give an honest and good try to something else or don't even have time.

Also it's what's taught in courses as superior to non relational databases.

I would not change our MongoDB clusters for Postgres/MySQL/etc even if I could do it with a single command. In this case it's not relational data though, for a large business relational model I would stick with RDBs.

If you are looking for a document store there aren't many alternatives. And one of the positive elements of MongoDB has been that they acknowledged their many issues and have over the years been fixing them one by one. Whilst alternatives have largely been stagnating.

And I am still yet to find any database that even comes close to its single tuple update speed.

Have you looked at postgresql document store? Amazon put a mongodb API on that and made a service after all

1) No that's not what AWS did at all. They implemented the MongoDB API on top of their own storage layer. It doesn't use PostgreSQL.

2) Of course. But MongoDB is orders of magnitude faster in some cases, has better horizontal scalability capabilities, better drivers and some nicer semantics e.g. around streaming.

It’s webscale!

I actually recognize threeseed's name over the past five years as being a staunch MongoDB proponent.

https://hn.algolia.com/?sort=byPopularity&prefix&page=0&date...

No hate, just always amused me that someone on HN had MongoDB as their hobby horse.

https://news.ycombinator.com/item?id=18870397

Over the last few Months we’ve switched over to amazons document db just to have a managed service. We don’t regret it.

DocumentDB is still really expensive as there's no pay what you use option.

I stored about 2KB of data for 72 hours and got charged fifteen dollars before I realised the mistake.

They really need to come up with a per mb per hour option.

What?!? I’m a big AWS skeptic for most people but this sounds insane. Details?

The cheapest option is 0.277$/hr just for the instance.

https://aws.amazon.com/documentdb/pricing/

It's interesting that people would pay amazon, but not mongodb...

I work in the enterprise and we spend tens of millions a year with AWS.

Our Security, Cloud Engineering and Finance teams understand VPC, IAM, Costs etc back to front and so when you add a new AWS product they know how to manage, secure, finance and support it. And of course there is no Procurement process with adding a new AWS product.

With a managed MongoDB (even though it's on AWS) you need to get buy in from dozens of people and go a vendor comparison to get through Procurement. It's why for many companies AWS dominates and in the future could well end up owning everything under the application layer.

I guess nobody got fired for buying IBM is still true to this day and age.

This still doesn't sound like a good reason to pay AWS instead of MongoDB. Didn't your Security, Cloud Engineering and Finance teams have no understanding of AWS at some point? Why can't they start to 'understand' how a managed MongoDB works, and give buy-in?

There's a common saying we have in our consulting circles, that "Processes should support business, but business decisions shouldn't be made because of lack of processes".

We had a large local bank choose not to pursue a good opportunity because "our procurement process takes too long". This instead of investing in fixing the procurement process.

If your choice is between (1) get MongoDB support from AWS and (2) get MongoDB support direct from MongoDB, the fact that Security, Cloud engineering and Finance know AWS and how to work in their environment seems to be the obvious choice. The difference between (1) and (2) is probably minimal enough to make the existing relationship with AWS meaningful. I don’t know enough about the costs of the two, but it’s possible that the incremental cost for adding it to AWS was cheaper.

My point is that those support functions' lack of understanding of realms outside of AWS shouldn't be the sole motivator for not using a technology.

What happens if a company that uses Software A has good motivation to use B, but their support functions don't understand B? Aren't the support functions supposed to improve by seeking to understand B, even at the initial inconvenience of time and resources?

I certainly don’t disagree with you on principle. It’s just a bad example in this specific case because A is roughly equivalent to B in this case.

Also, Amazon doesn’t have the same reputation as Google for killing products, so it’s a pretty safe bet. And AWS will be around for quite a long time. The financial stability of MongoDB (the company) isn’t as guaranteed.

Maybe the parent’s company’s processes did work in this case.

They're roughly equivalent, but what if B costs a tenth of A?

It's not about the safety of the bet, because from an OSS perspective, the issue seems to be that many are moving away from MongoDB to something even more opaque. I don't follow AWS, but do they publish a roadmap of planned changes in their document DB?

Does Google have a reputation for killing Enterprise products? I thought it was just consumer products that they offer for "free" that are subject to getting the axe.

Don’t try to make sense of it, it doesn’t.

In a .gov environment, we literally paid 5x more for certain services because the contract terms demanded were too costly or onerous for OEMs to handle. So everything funneled through middlemen of dubious value, who basically borrowed money, pushed paper and carried insurance for a vig that pushed up the price.

The procurement people were very happy, because they got their three bids that varied less than 1%.

Would you bring a single Windows server into a Linux shop? This is the same, but most of the cost is administrative instead of technical.

Unfortunately that’s typical in enterprises. Procurement staffers are typically not technologists, rather they are contract wranglers, responsible for setting terms with vendors that have longevity, references, willing to negotiate, approved by security, are provably better than at least two comparable competitors, etc. If you want to sell to enterprises you have to bend the knee to their procurement team.

MongoDB Inc wrote MongoDB, which is a major black mark against them.

I actually use MongoDB Atlas for the same app now, because my usage fits in the free tier.

https://aws.amazon.com/documentdb/pricing/ At $0.277 it’s $19.94 for 72 hours.

I spend somewhere around $30-40k / yr on AWS (EC2) for a 3 member replica set.

I evaluated DocumentDB and price wasn’t the issue (at our scale, the price is OK).

Main blocker is that it’s locked at Mongo 3.4 API compatibility, which is several major versions behind. But worse, their implementation of the 3.4 API is incomplete, so while they advertise “Mongo Compatible”, it really isn’t a drop in replacement.

Google Cloud's managed SQL seems to have an option where the instance spins down automagically when its not in use.

Super expensive and orders of magnitude slower in some cases.

As much as I love a managed service this was a very disappointing effort from AWS.

I would love to see open source developers and companies supported because it's not really tenable to replace all the open source we rely on - we probably need 20 million lines of open source to serve a HTML page. If we were actually enabling and empowering open source developers, and especially the people learning, it would be awesome. Enabling people like Torvalds and Stallman to grow into their role of writing stuff that benefits billions of people.

But we can do Hunger Games too. There's no wrong answers.

I dunno, I could do it in 200 of good code in C.

Including kernel, network driver, etc?

I guess not no, I was thinking of userland.

You can make a simple HTTP/1.1 server in 200 lines of good C. Not one that runs HTTP/3.0 including QUIC and TLS.

HTTP 3 isn't even in production yet.

Define production and define HTTP3. The beauty of open source is that you can be already serving pages using QUIC and TLS1.3 while the standard is being finalised.

A finalised standard was what I had in mind. QUIC, much like SPDY was, isn't more than a Google protocol for only Chrome right now.

99% of websites do not need anything beyond HTTP/1.1.

For my side project/startup (volunteer management and organisation for NGOs and political campaigns) I fell right into the trap.

I'm not enough of a DB person to know if it was Mongo, or the ORM I was using (Waterline), but my data is extremely structured and relational. Once I switched over to Knex/Objection with a Postgres DB, everything went much smoother. The transition, though, took around two months, was hell, and I almost turned back many times.

Ubiquiti is one of those companies. They use MongoDB for their controller app, which has been a pain in my side for a couple of years now.

Didn’t Stripe go down this road?

Yes, in addition they apparently use a pretty outdated version of it. (Several people mentioned this on a related HN thread that I'm having trouble locating.)

It was claimed here [0]

>... they continue to build on top of a broken foundation (MongoDB) ...but last I heard Stripe was still running a very outdated version ...

[0]https://news.ycombinator.com/item?id=20820879

Coinbase comes to mind.

Include in that any of the many companies still using Perl, for whom MongoDB have dropped library support.

A lot of startups for sure

Reply on news.ycombinator.com