10 ms·

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

mikeryan 7y ago
Over the last few Months we’ve switched over to amazons document db just to have a managed service. We don’t regret it.
- nailer 7y ago
  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.
  - qeternity 7y ago
    What?!? I’m a big AWS skeptic for most people but this sounds insane. Details?
    - smnrchrds 7y ago
      The cheapest option is 0.277$/hr just for the instance. https://aws.amazon.com/documentdb/pricing/ https://aws.amazon.com/documentdb/pricing/
      - chii 7y ago
        It's interesting that people would pay amazon, but not mongodb...
        threeseed 7y ago
        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.
        chii 7y ago
        I guess nobody got fired for buying IBM is still true to this day and age.
        nevi-me 7y ago
        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.
        mbreese 7y ago
        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.
        nevi-me 7y ago
        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?
        mbreese 7y ago
        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.
        peteretep 7y ago
        MongoDB Inc wrote MongoDB, which is a major black mark against them.
        nailer 7y ago
        I actually use MongoDB Atlas for the same app now, because my usage fits in the free tier.
    - rad_gruchalski 7y ago
      https://aws.amazon.com/documentdb/pricing/ https://aws.amazon.com/documentdb/pricing/ At $0.277 it’s $19.94 for 72 hours.
  - cj 7y ago
    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.
  - farisjarrah 7y ago
    Google Cloud's managed SQL seems to have an option where the instance spins down automagically when its not in use.
- threeseed 7y ago
  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.
benologist 7y ago
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.
- mruts 7y ago
  I dunno, I could do it in 200 of good code in C.
  - est31 7y ago
    Including kernel, network driver, etc?
    - mruts 7y ago
      I guess not no, I was thinking of userland.
      - est31 7y ago
        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.
        cameronbrown 7y ago
        HTTP 3 isn't even in production yet.
        xchaotic 7y ago
        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.
shanev 7y ago
Coinbase comes to mind.
taylorlapeyre 7y ago
Didn’t Stripe go down this road?
- enraged_camel 7y ago
  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.)
  - delhanty 7y ago
    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 https://news.ycombinator.com/item?id=20820879
threeseed 7y ago
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.
- mfer 7y ago
  Have you looked at postgresql document store? Amazon put a mongodb API on that and made a service after all
  - threeseed 7y ago
    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.
    - species9606 7y ago
      It’s webscale!
      - hombre_fatal 7y ago
        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&dateRange=all&type=comment&query=threeseed%20mongodb 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.
    - phonon 7y ago
      https://news.ycombinator.com/item?id=18870397 https://news.ycombinator.com/item?id=18870397
Thorrez 7y ago
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)?
- zxcvbn4038 7y ago
  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.
  - scarface74 7y ago
    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.
    - 6nf 7y ago
      So why not just use a RDMS from day one?
      - scarface74 7y ago
        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.
peteretep 7y ago
Include in that any of the many companies still using Perl, for whom MongoDB have dropped library support.
pfarnsworth 7y ago
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.
truth_seeker 7y ago
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?
- deleted 7y ago
  [deleted]
- octohedron 7y ago
  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.
IloveHN84 7y ago
A lot of startups for sure
Benjamin_Dobell 7y ago
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.
- SergeAx 7y ago
  What is the point of running containerized DB server in production? Isn't it an anti-pattern?
  - Benjamin_Dobell 7y ago
    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.
    - SergeAx 7y ago
      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?
bszupnick 7y ago
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.

mikeryan 7y ago

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

nailer 7y ago
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.
- qeternity 7y ago
  What?!? I’m a big AWS skeptic for most people but this sounds insane. Details?
  - smnrchrds 7y ago
    The cheapest option is 0.277$/hr just for the instance. https://aws.amazon.com/documentdb/pricing/ https://aws.amazon.com/documentdb/pricing/
    - chii 7y ago
      It's interesting that people would pay amazon, but not mongodb...
      - threeseed 7y ago
        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.
        chii 7y ago
        I guess nobody got fired for buying IBM is still true to this day and age.
        nevi-me 7y ago
        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.
        mbreese 7y ago
        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.
        nevi-me 7y ago
        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?
        mbreese 7y ago
        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.
      - peteretep 7y ago
        MongoDB Inc wrote MongoDB, which is a major black mark against them.
      - nailer 7y ago
        I actually use MongoDB Atlas for the same app now, because my usage fits in the free tier.
  - rad_gruchalski 7y ago
    https://aws.amazon.com/documentdb/pricing/ https://aws.amazon.com/documentdb/pricing/ At $0.277 it’s $19.94 for 72 hours.
- cj 7y ago
  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.
- farisjarrah 7y ago
  Google Cloud's managed SQL seems to have an option where the instance spins down automagically when its not in use.
threeseed 7y ago
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.

benologist 7y ago

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.

mruts 7y ago
I dunno, I could do it in 200 of good code in C.
- est31 7y ago
  Including kernel, network driver, etc?
  - mruts 7y ago
    I guess not no, I was thinking of userland.
    - est31 7y ago
      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.
      - cameronbrown 7y ago
        HTTP 3 isn't even in production yet.
        xchaotic 7y ago
        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.

shanev 7y ago

Coinbase comes to mind.

taylorlapeyre 7y ago

Didn’t Stripe go down this road?

enraged_camel 7y ago
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.)
- delhanty 7y ago
  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 https://news.ycombinator.com/item?id=20820879

threeseed 7y ago

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.

mfer 7y ago
Have you looked at postgresql document store? Amazon put a mongodb API on that and made a service after all
- threeseed 7y ago
  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.
  - species9606 7y ago
    It’s webscale!
    - hombre_fatal 7y ago
      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&dateRange=all&type=comment&query=threeseed%20mongodb 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.
  - phonon 7y ago
    https://news.ycombinator.com/item?id=18870397 https://news.ycombinator.com/item?id=18870397

Thorrez 7y ago

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)?

zxcvbn4038 7y ago
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.
- scarface74 7y ago
  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.
  - 6nf 7y ago
    So why not just use a RDMS from day one?
    - scarface74 7y ago
      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.

peteretep 7y ago

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

pfarnsworth 7y ago

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.

truth_seeker 7y ago

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?

deleted 7y ago
[deleted]
octohedron 7y ago
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.

IloveHN84 7y ago

A lot of startups for sure

Benjamin_Dobell 7y ago

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.

SergeAx 7y ago
What is the point of running containerized DB server in production? Isn't it an anti-pattern?
- Benjamin_Dobell 7y ago
  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.
  - SergeAx 7y ago
    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?

bszupnick 7y ago

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.