This brings back some memories from 2012. I was updating an internal tool at the company where I worked, and after a lot of thought I decided to replace a tried

This brings back some memories from 2012. I was updating an internal tool at the company where I worked, and after a lot of thought I decided to replace a tried and true MySQL database with Mongo. It really seemed like a good idea at the time - we were storing loosely related documents where not having a fixed schema was an advantage. Any advantage I got was lost by the time I built all the logic to handle the joins I did need to make (those join keys weren't so schemaless after all). And then I needed logic to make sure every record had the right keys, that they made sense, etc. This was all stuff that MySQL had been doing for me. But the real kicker was that Mongo made my performance worse. When I migrated my database (roughly 10 million records), I compared before and after sizes of the actual files. Mongo's were 2-3x the size. I didn't realize it before starting, but Mongo's preallocation model gave me huge files with sparsely written records that had room for future updates. But I didn't need that extra room because my data rarely changed. So I ended up with larger files that took longer to scan for unindexed queries (mostly for reporting), which meant I had to index more stuff, which increased my memory usage, and forced me to upgrade to larger servers. Had I stuck with MySQL, I would have been fine. Many expensive lessons were learned from this, which I guess was valuable.