181–190 of 224 posts
Off course it was, prototyping speed on mongodb was (and probably still is) always excellent. Some features that don't scale are very nice to have when you don't have scaling issues. For example, if you add tags to your documents and you want to query on those tags (find all documents containing tag A and B), it's nice that's just a builtin. I haven't found a single datastore that is as developer friendly that suppor…
I would argue that MongoDB is not—and has never been—the best choice for solving any particular technical problem. But it had some other "advantages" over other, better solutions – in that it was easier to set up, didn't require schema definition, had a passable clustering story etc. I have worked with at least one company that had been built using MongoDB as a primary data store from day one. This caused untold pain…
Postgres is not an alternative to Mongo, though. Provide a noSQL alternative if you want an alternative. RDBs and non-RDBs seek to address different sets of problems, and sometimes you do not want or need a relational database.
I went to production with Mongo and it exceeded my expectations. It operated without a single issue for years under high load. It was a dream to administer and a vital piece of a multimillion dollar franchise. Everybody else I know, however, has had nothing but headaches. They’re the same reasons I’ve seen people fail at using Cassandra, Redis, or Spanner. If you can’t adjust to the limitations and paradigm shift, yo…
As with anything, it depends on the project. I’m working on an internal service that uses Mongo as a single merged cache for a lot of mostly unchanging data from various data stores with different credentials for each, which are distributed around the world, that we otherwise have to fetch through multiple comparatively slow API calls. For this, Mongo is perfect: no messing with schemas as they change, unannounced, f…
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. Fortnite uses MongoDB for everything, they have a huge load ( 7.5M CCU is insane ) and don't have more problems than if they choose something else. MongoDB gets bad press on Reddit / HN probably because of past marketing campaigns, but nowdays it's a very solid solution.
> "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.
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.
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.
I would argue that MongoDB is not—and has never been—the best choice for solving any particular technical problem. But it had some other "advantages" over other, better solutions – in that it was easier to set up, didn't require schema definition, had a passable clustering story etc. I have worked with at least one company that had been built using MongoDB as a primary data store from day one. This caused untold pain…
I would argue that MongoDB is not—and has never been—the best choice for solving any particular technical problem. But it had some other "advantages" over other, better solutions – in that it was easier to set up, didn't require schema definition, had a passable clustering story etc. I have worked with at least one company that had been built using MongoDB as a primary data store from day one. This caused untold pain…
As a n00b when it comes to web development I've sort of given up on fretting more than "too much" about "Is this the best way?" and focused on "let's try some stuff and it doesn't work I'll learn from it and make a better choice when I come to it". There seems to be a cost associated with evaluating optimal paths. Personally I get SQL (well enough to use it) and I can work with so I don't bother with MongoDB much, bu…
I know this but I keep ignoring it ¯\_(ツ)_/¯
I'm still in charge of a production system serving around 2,000 small to medium websites from a 2-machine MongoDB cluster. It's been running on MongoDB since around 2010 and we have NEVER had any issues. I accept that the unacknowledged writes was a bad decision, but IMHO if you deploy a new database without reading the documentation, you have bigger issues. The reality is that there are some places where speed of mo…
1. Writing DDL is not hard. It's just not very hard. 2. You can go from strict guarantees to looseness safely, when you demonstrably need to. The reverse isn't true -- it's easy to wind up realising, much too late, that you actually needed particular guarantees that you didn't even think of. Relational databases didn't become incredibly popular by accident. It's because they were a drastic improvement -- theoreticall…
If you are just using one table with two fields (id/value and value contains a json object that changed) for logging perhaps a relational database isn't the right choice. Redis might be better / mongo might be better depending on what comes next.
Let's stop the next cycle where everyone moves to postgres for everything only to throw it away for the next thing. I was using postgres in 2008 and it was great.. why did it take until 2019 for everyone else to discover? We are in the peak postgres cycle. I hope it doesn't get disgarded when the serverless hype kicks into gear.