Live data from Hacker News

Was MongoDB Ever the Right Choice?

simplethread.com

221–224 of 224 posts

Re: Was MongoDB Ever the Right Choice?

#221
post #185
post #175

Earlier quoted context omitted.

> "passable clustering" you talk about PG which has nothing, so when you start to re-implement sharding yourself you're in trouble. Or you can just use Citus.

Which is not PG anymore.

Citus is an extension to Postgres. It is still PG, and has the same scaling semantics as a MongoDB replica set that that point for distributed tables.

Re: Was MongoDB Ever the Right Choice?

#222
post #37

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…

How do you _know_ you never lost data?

Ha! Good point. Customers would complain quickly enough.

Re: Was MongoDB Ever the Right Choice?

#223
post #37

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…

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 complexit…

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.

Re: Was MongoDB Ever the Right Choice?

#224

Earlier quoted context omitted.

ElasticSearch does most of what you are saying in the box, can even have each day read into a different collection and query them on joined aliases. At least IIRC, I'm not an expert. When I first tried using it and Mongo, I had issues with ES geo indexing, but since then have used both with little issue. Just depends on the scenario.

Latest ES supports purging expiry based on a time field I believe, but before that you were creating daily/hourly indexes and haggling with elastic curator to delete them. There is also no meaningful way to do it by logical size. Elastic is great in it's own sense, but it's not as flexible as mongo when it comes to schemas.

Agreed... I didn't know it allowed for time expiry now, been a couple years. I just find that at least half the time where I would consider Mongo today, ES seems to be a better fit. If PG was nearly as easy to setup replication hot/auto fail over, I'd probably favor that 95% of the time. I really wish RethinkDB had been as successful with marketing as Mongo though.
Post reply on HN