It is still in production as the main database in a startup I joined in 2010 and kicked off their software's development. I've been through smaller ups and downs, but we never lost data. The reason why I loved it back then and still do today (I'm using mongodb in my own little webapp) is the speed of development. The few data migrations that I had to write in over eight years where nothing compared to what you'd have to do in a relational database. With new features we were always able to keep the db schema in some state of fluidity on our dev and staging machines until we we happy with the data's architecture. No back and forth that you'd do with a relational database.
We have only a dozen collections in the db and only four where pulled during a normal user session but those translate not just into four models/classes but a few more embedded ones, which makes totally sense because except for reporting we didn't pull out the embedded data, even though it has become so much smoother with the aggregation framework.
It sounds like your product was in the sweet spot where there isn’t much data complexity or evolution, and the schema is understandable and easy enough to modify over time without strictness.
The product I work on has ~400 tables active at the moment, and ~800 that have ever existed in it over the last 6 years. We depend on the database schema to reduce complexity at the application level.
I don’t think the complexity would be manageable at the application level if we couldn’t do this. At least not with the ~6 engineers working on it.
That's about six times the engineering power you have there.
Our data is indeed simple and beside data collection via a web app, the focus is on reports with that data; but always in small sensible junk and never across the whole available data for a model.
