221–230 of 243 posts
Seems like nobody wants to use MongoDB, but at the same time it’s a $12B public company whose stock price is surging. Is MongoDB the new mini-Oracle?
Earlier quoted context omitted.
While there are many people here who are sharing their bad experience with MongoDB, just curious if you all find the experience with DynamoDB similar? Since they are both of the NoSQL family.
DynamoDB is a lot more explicit about its tradeoffs. Much of the backlash against Mongo was because it basically claimed to be well-suited to any use case, when its sweet spot was really far narrower. To be successful with Mongo, you need to design the entire app around its limitations, but those limitations were initially downplayed and obscured. People were convinced that Mongo was a good choice as a default, gener…
More importantly, AWS is very explicit in letting newcomers be perfectly aware that DynamoDB's usecases are, that they are very specific niche use cases, and that if users require schemas and joins then they should just stick with either relational databases or graph databases.
Those who overpromise will always disappoint.
Earlier quoted context omitted.
This is not true. I'm using it because the cost of changing the schema for a feature that may only be experimental is too high. I started off changing the schema every time, and it just got too expensive. Using the JSON-to-SQL workflow, I can mess around with feature design and iterate fast, and then crystallise the schema into SQL once it has stopped changing. Writing solid migrations can end up being more complex t…
> This is not true. Everything or certain parts of it? > Using the JSON-to-SQL workflow, I can mess around with feature design and iterate fast, and then crystallise the schema into SQL once it has stopped changing. Sure, you're experimenting and things are in a state of flux. I get it. Been there done that, but not in production. Your customers want features over reliability. This is perfectly OK at a startup - the…
Earlier quoted context omitted.
> You make technical decisions based on what happened a decade ago? Do you make all decisions based on ten year old information? Yes? The problem was not that MongoDB was young, the problem was that authors of it had no idea about databases when they started their work. They stored data in RAM and get fastest benchmarks, because they didn't worry about persisting the data on disk. They outright lied in their document…
> They outright lied in their documentation about the guarantees. > It wasn't the being early product part, it was the misrepresenting the truth part that hurt their credibility. That's why I replied to the person you're responding to that his view of software development is cartoonish, but I don't think he got it. > the problem was that authors of it had no idea about databases when they started their work Speaking…
What do I define as "document-DB-appropriate"? Blobbed stuff where you want it all in the same document sized doses, and always the same dose, to the point where you feel ridiculous putting bits together in the same shape over and over and notice that you CRUD the same dose/shape all day... Objects...
Don't get me wrong, there's times in computer data land when the first 128 bytes are the header and that the data is multiplexed in 32bit chunks with 24 bits zero-padded and this padding tells you "channel 2 is starting now buddy!"
But SQL is certainly a viable option for many things and rather standard and known and supported and stuff...
Yes, use it with Atlas for every one of my companies' projects. - The document model is a no-brainer when working with JS on the front-end. I have JSON from the client, and Dictionaries on the backend (Flask), so it's as easy as dumping into the DB via the pymongo driver. No object relational mapping. - Can scale up/down physical hardware as needed so we only pay for what we use - Sharding is painfully easily, with o…
No. Every time I've used mongodb we've ended up regretting it for one reason or another. And migrating to a different database after launch is a huge hassle. I've done a couple projects where we kicked off with postgres using JSONB columns for early iteration. Then we gradually migrated to normal SQL columns as the product matured and our design decisions crystallized. That gave us basically all the benefits of mongo…
Yep, just regret and misery. Back in 2010 when the MongoDB hype was high, the well-known company where I was working at the time decided to build the next version of the product using MongoDB. I was on the analytics team and had to code a whole bunch of intricate map-reduce jobs to extract summary data out of Mongo. I'd repeatedly head to the product team and ask them to explain the edge cases I was seeing in the dat…
Iirc, they've turned around on their anti relational views and now allow for joins.
I looked at OrientDB awhile back ago, but it fell flat with the lack of features and oddness.
If I had more time, I would really dig into ArangoDB.
I've actually never used it, and probably won't at this point. But, we do use Couchbase at my workplace, and it's worked well for us. The use case is very limited in scope, but it serves our purposes well. I'd be curious to know how they compare from folks who have used both?
Depends on what you're doing, I suppose. CouchDB's multimaster concurrency features are still effectively best in class, but there are so many managed DB services now, that it doesn't seem like a headline feature. The RESTful interface is pretty cool. And Couch's in-built security features are near enough a best kept secret. CouchDB always lost to Mongo in discussions about speed unfortunately. Data safety and securi…