101–108 of 108 posts
Will meet similar fate like Twitter, Snapchat...
Perhaps, but wouldn't it make sense to compare them to another software infrastructure company, rather than social networks?
Earlier quoted context omitted.
>their market just isnt big enough the database market is one of the biggest software markets out there, if not the biggest. >their losing a lot of steam as of late at least according ot google trends, mongodb is more popular than ever. >last effort cash out sort of deal to me they're hiring like crazy and looking to grow a ton in the next year, so I don't think that's the case.
Did you consider that perhaps projection of growth is exactly what you'd do in the event of an IPO? Or that Google trends isn't a sensible heuristic for a valuation? I've down-voted you not because I disagree fundamentally (although I don't rate MongoDB) but because you are dismantling an argument badly. I hope that isn't too rude.
Earlier quoted context omitted.
Perhaps, but wouldn't it make sense to compare them to another software infrastructure company, rather than social networks?
I am not comparing them but simply predicting the fate based on overblown expectations that were similar to Twitter and SnapChat.
Really? I thought the MongoDB fad had gone away, that common sense returned, and people either used proper document stores, or proper relational databases, or graph databases.
Could you be a little more specific as to what a proper document store is? Mongodb has impressed me after using it for two years in a highly concurrent and rapidly changing big data production system. It's not without its significant headaches, but I've yet to find a database that is.
http://www.sarahmei.com/blog/2013/11/11/why-you-should-never...
http://cryto.net/~joepie91/blog/2015/07/19/why-you-should-ne...
https://news.ycombinator.com/item?id=9912842
http://developer.olery.com/blog/goodbye-mongodb-hello-postgr...
Earlier quoted context omitted.
Could you be a little more specific as to what a proper document store is? Mongodb has impressed me after using it for two years in a highly concurrent and rapidly changing big data production system. It's not without its significant headaches, but I've yet to find a database that is.
There are many articles out there on the web, over the last 5 years, addressing the many problems specific to MongoDB. For example: http://www.sarahmei.com/blog/2013/11/11/why-you-should-never... http://cryto.net/~joepie91/blog/2015/07/19/why-you-should-ne... https://news.ycombinator.com/item?id=9912842 http://developer.olery.com/blog/goodbye-mongodb-hello-postgr... https://www.andreas-jung.com/contents/goodbye-mongo…
It looks like the NoSQL movement was just a fad and plenty of startups got burned by it and some still stuck with this tech , writing inefficient workarounds for something that comes OTB with the regular SQL databases.
There are a good reason to use NoSQL, for example to replace EAV. But definitely not a good use to do everything on NoSQL so most companies opted out for 2 database solution = SQL + NoSQL and did not get burned. The thing however is that since Postgres released indexed BSON support (which is actually faster then MongoDB) there is absolutely no point in opting for 2 database solution and making things harder for no re…
Earlier quoted context omitted.
Reliability and implementation ideas aside, MongoDB popularized document stores and document stores can sometimes be a good thing (even if there's usually little to no reason to prefer them to plain SQL databases for most applications). So they deserve credit there.
Agreed; though the way they did their marketing early on the message they conveyed was that document databases were here to replace RDBMSs. It was extremely dishonest.
The CTO still thinks so. Quote[0]: "MongoDB's CTO disagrees with this statement arguing that nearly 90% of database installations today would benefit from being replaced with MongoDB"
Earlier quoted context omitted.
There are a good reason to use NoSQL, for example to replace EAV. But definitely not a good use to do everything on NoSQL so most companies opted out for 2 database solution = SQL + NoSQL and did not get burned. The thing however is that since Postgres released indexed BSON support (which is actually faster then MongoDB) there is absolutely no point in opting for 2 database solution and making things harder for no re…
Or, get the best of both worlds. ToroDB puts a mongo wire protocol in front of Postgres, which outperforms mongo significantly on the same hardware. Plus, you can get read-only views on the Pg side to join with traditional relational data.
Postgres alone is already the best of both worlds. With ToroDB, I am restricted to the MongoDB way of dealing with my data; with Postgres, I can mix SQL and NoSQL however I like, even in a single, simple SELECT query.