11 ms·

MongoDB isn't usually seen favorably but everyone must admit that it's an unlikely success story that deserves admiration. Think about it. Bringing a database t

• enjo 9y ago
  It really is an interesting story. They aren't best in class in any of the metrics we think of as mattering. It's not the highest scale system out there. It's not the most durable. Or the most available. Hell it's not even particularly reliable (at least throughout its history). It is however..simple. Very simple. It's easy to reason about. It's easy to setup. For 90% of use cases it's very easy to administer. It turns out the market for that type of data store. Something you can apt-get install and just start dropping data into is pretty massive. I've used MongoDB on a few occasions. Usually thinking I'm just using it to bootstrap a project, but three years later it's still running because it's just good enough to keep me from moving on to something else.
  • zitterbewegung 9y ago
    Developer ergonomics are way more important than many features to get wide adoption. You can fix the other things with time. Worse is better.
    • brianwawok 9y ago
      Except when you poison mindshare. For example, I used Mongo back in the early days. Was terrible. I will now never use it again. I don't care if it shoots lasers. It is dead to me. Obviously the happy developer count is way more than the hate it for life count, so I am the odd man out here. Perhaps many users never actually had many GB of data or had to deal with the data loss side of things?
      • jsjohnst 9y ago
        [apparently my opinion is unwanted]
        • jjnoakes 9y ago
          Let's tone down the drama a little; I am willing to bet there aren't many people at all who would literally choose to lose their home versus work with a technology they don't like (even if for valid reasons, and even if those reasons include data loss or other catastrophes). If my boss tells me to use MongoDB tomorrow or live on the street despite my advice to the contrary, I will use MongoDB happily. I may look for a new job in my free time if using MongoDB makes me miserable, but I certainly won't be living on the street...
          • jsjohnst 9y ago
            [or maybe the fact I watched a hundred million $ startup go down the drain in part due to bad engineering choices, of which Mongo was one, doesn’t entitle me to a negative opinion of Mongo]
            • jjnoakes 9y ago
              You can say you'd choose to be homeless all you want, but saying "many" would do the same I think is being a little too dramatic. And quitting your job (as you now point out, but didn't originally) is much different from "choosing to be homeless".
              • jsjohnst 9y ago
                I used the word quit in my very first post on this thread in a way that should’ve been obvious I meant quit my job.
                • jjnoakes 9y ago
                  It wasn't the word "quit" that was being objected to though; it was your equating quitting to being homeless (in the very same first post in this thread) and then further saying you think many others would also rather quit and be homeless than work with MongoDB. That's a bit too dramatic. Next time, just say "I'd rather quit than work with MongoDB again", and you won't have this problem.
  • stanfordkid 9y ago
    It really was the first NoSQL database that many programmers used -- and it came out right around the same time that JSON was really taking off. The timing was perfect, the product was simple. Fact is most people don't really need insane scale and there are thousands of use cases where you just need to read and write JSON and fetch things by a few different fields. I think they nailed it. Every other NoSQL DB out there at the time was insanely hard to "just play with" (e.g HBase, Cassandra etc.) I think you hit the nail on the head -- for many programmers who were "coming of age" at that time Mongo was the easiest to experiment with and to get working.
    • devdad 9y ago
      This is me - I had taken SQL at uni and found MongoDB to be much easier to reason about since I knew my frontend parts already. One of the apps I've built has a terrible database structure (my first real life server setup!), and is probably the worst codebase I've ever written. I will never show it publicly. It currently serves 100k+ users and the users have no idea how messed up the server code is. It won't scale to a million users, but that's okay and the technology served me well as a junior. I since turned to RethinkDB and sometimes just a classic SQL will do, but Mongo is really easy to get started with.
    • pessimizer 9y ago
      > It really was the first NoSQL database that many programmers used That was because it was heavily marketed, not because of timing. > Mongo was the easiest to experiment with and to get working. It really wasn't, it was the one they had heard about.
  • adamnemecek 9y ago
    > It's easy to reason about. ...until it's not. Then it's really not.
    • sametmax 9y ago
      But how many people reach this stage ?
      • adamnemecek 9y ago
        It's a gradual process and you start feeling the pain fairly early on.
      • yeukhon 9y ago
        It starts really early on. When I first used MongoDB I thought to myself "what a fresh breath, I can finally ignore normalization!" The documents I inserted would contain all the information I needed. One retrieval and I got what I needed. Wow!! But then I started doing sorting, searching and I had to do most of the work on the client side (my backend). At that point, I found myself in trouble because in my other tables I also dup my information. Data has to be updated in multiple places. So I thought "let's take out the dup data." Then I found myself not knowing how to structure my document data anymore... back to some sort of normalization. At the time the searching and ranking in MongoDB were also poor, so I was forced to doing the entire thing on the client side regardless. I went back to PostgreSQL since. I probably needed a good one-on-one expert training with MongoDB, but I just found myself happier with RDBMS. You don't have to be strict normalization in RDBMS, just enough to make sense for your use cases. One thing I really did like about MongoDB back then was storing blob (files). It was the best solution available without setting up S3. At the time there was a limitation with 4GB (??) but MongoDB worked for my use case anyway. That being said, please don't store files in any databases today. Use DB to store references to a real object storage like S3. When the DB crashed, you better hope no corruption.
        • goldfishcaura 9y ago
          It amazes me how quickly our industry has forgotten the need for DBAs. With these MongoDBs, MPP cloud dbs and Hadoops, everyone seems to have assumed that engineers can now do all db work. This is reflected in the titles too: Data "Engineer". But from my perspective, this is delusional. There is a lot that goes into DBA's experience that is not solved by the performance improvements in databases over the past decade. But there are more choices. 20-30 years ago, you would have been forced to write code on Oracle and you would have asked for help before deciding how to structure the data. Today, with more choices, you just read some online opinions, and jump on it without any internal resource to guide you. Not saying the world of Oracle was great, but the young on this thread (me included) would benefit from respecting the experience of the old.
  • derefr 9y ago
    > It is however..simple. Very simple. It's easy to reason about. It's easy to setup. For 90% of use cases it's very easy to administer. I think most of HN would feel this way about, say, Redis. And Redis isn't "highest scale" or "most durable" or "most available" either. (Though it is pretty reliable.) It's interesting, then, to compare the general impression people here have to MongoDB to the one they have of Redis. To me, Mongo is a "why use it when Postgres is just as easy to install", while Redis is exactly what I'd think of "to bootstrap a project, but three years later it's still running." Is it just the slightly-different pitched use-cases of "working store" (Redis) vs "persistent store" (Mongo)? Is it that Redis still has its uses even when you've got Postgres there beside it, whereas Mongo doesn't so much (at least since Postgres got JSON columns)?
    • nemothekid 9y ago
      Redis makes very different promises than mongodb. Redis has always documented how exactly persistence works and how you could lose data. Redis' benchmarks arent dishonest. Redis isn't marketed as a SQL replacement nor as a primary data store.
  • RHSman2 9y ago
    Have you ever tried to write a mongo query? Simple, it is not.
  • rareattention 9y ago
    >They aren't best in class in any of the metrics we think of as mattering. MongoDB is the best in class at how programmer-friendly it is. Its API is easy to work with. This is especially the case if you are using node and javascript.
• user5994461 9y ago
  Depends what you mean by production ready. Sure thing, $192M is not a billion dollar business.
  • yaseer 9y ago
    $192M is the value of the shares sold in the IPO. The MDB's market cap, i.e. it's valuation, is around $1.17 billion as of the time this article was written: https://www.cnbc.com/2017/10/18/mongodb-prices-its-ipo-worth-1-point-2b.html https://www.cnbc.com/2017/10/18/mongodb-prices-its-ipo-worth... EDIT: Added 'billion'
• inferiorhuman 9y ago
  > Bringing a database to the market with a completely different paradigm, growing it to the enterprise-production-ready level Neither of those are true, however.
  • threeseed 9y ago
    It was the first, well known, company supported JSON document store. It is being used by Facebook, Metlife, Expedia, Sony, eBay, Adobe etc. In what way isn't it ready for production use cases ?
    • praneshp 9y ago
      > In what way isn't it ready for production use cases ? Your parent commenter doesn't like Mongo. So it's not production ready.
      • inferiorhuman 9y ago
        > Your parent commenter doesn't like Mongo. So it's not production ready. Eh I don't like Mongo because I've used it. IDK, it's been a few years since I've had to deal with mongo in a production environment. I don't miss it. I dislike that it's slow to get data to/from the javascript interpreter -- and that the solution was to work around it with the aggregation framework. I don't like the unsafe defaults (data integrity, access control). I don't like the magical, unreliable sharding that you have little to no control over.
    • flukus 9y ago
      You need more than just a list of companies using it, you can create a similar list for just about any technology, good or bad. Sony is a worldwide company with 127,000 employees, they alone probably use just about every database system around. So saying sony uses mongo isn't impressive, for all we know it was just a side project from an intern that has 100 documents, there is no context.
      • threeseed 9y ago
• munk-a 9y ago
  If they had done so by presenting a product that was picked up due to it's merit and continued to gain traction based on that then I'd be rather impressed. Instead the story of MongoDB seems to be how extremely well targeted marketing and sales can build a so-so product into a huge IPO, there have been performance comparisons showing it isn't even the best at what it does so this IPO is riding on the network effect of those early stages of marketing alone. In our economy this is sadly an entirely valid route to making money but their mindshare is going to continue to collapse as the warts on their product show more and more. So the admiration you have should probably be directed at the wool the marketers behind MongoDB managed to pull over your eyes.
  • wnevets 9y ago
    >how extremely well targeted marketing and sales can build a so-so product into a huge IPO Thats how most products succeed if you ask me.
    • munk-a 9y ago
      I don't disagree, but we haven't seen them close the distance in terms of performance. Let me clarify a bit, I'm not saying that this tactic is invalid or inefficient within our current system, in fact this is a great way to land a good payday if you can pull it off. My point was more that MongoDB is going to implode when their performance shortfalls become visible to the wider populace, if that happens, of course. It's still possible they take the earnings from this IPO and dump heavy into R&D investment to make up the lost ground, but it's also very possible they take this payday and ride out the tech until it breaks down.
  • jameskilton 9y ago
    Ah, right, like RethinkDB? As much as I'd love this to be true, the #1 measure of success is if people even know you exist and #2 is if you solve enough of a customer's problems that it's worth using your product. MongoDB hit these two points hard right out of the gate and are now very successful because of it.
    • 9y ago
• flavio81 9y ago
  >it's an unlikely success story that deserves admiration Well, it's a success story due to marketing, smart marketing, clever marketing, and more marketing, not due to lots of technical merits. And it was not the first document store to appear, just the most successful. For starters, CouchDB was previous to MongoDB.
  • thawkins 9y ago
    Couch was a nightmare to use, mingo made all the friction to get it into products go away, especialy when teamed with dynamic languages.
    • jared0x90 9y ago
      Did you really find CouchDB that bad to work with? I never in the end settled on either couch or mongo for a project long term but when I setup couch to test it out a few years ago I had it up and running with functional replication quite quickly (i.e., one afternoon) from being a complete novice with the platform. It's built in web panel at the time basically handled everything from basic setup to replication quickly.
    • karmelapple 9y ago
      Using CouchDB on our team has been a pretty good experience; nothing like a nightmare. We used replication on the native apps for offline mode, kept things simpler with online-only for our web app, and have had a very good time overall. We are also using JSON schema for our CouchDB documents so we ensure we don't have all kinds of wild / wrong data showing up; if you had really hairy, unstructured data, I can see why a dynamic language might help with that bad situation, but for our use case, we were able to take advantage of the powerful replication built into CouchDB and get solid offline syncing for all of our native apps that also plays nicely with live updates in a web browser.
  • megaman22 9y ago
    Notes was a document store before JSON, or even XML was even a thing. The wheel turns.
  • 9y ago
• bborud 9y ago
  You forgot to mention: bringing a database to market that didn't work. Because for any real definition of "works" MongoDB didn't deliver on that. (Note: I used to be optimistic about NoSQL, but I was dismayed by the extremely low quality that NoSQL products started out at, and stayed at, for a very long time)
• matthew349hall 9y ago
  After a miniscule run-in with SQL, the only real DB I've ever touched is MongoDB (I've dabbled in redis). I've never understood the hate that MongoDB gets, but that's probably because I primarily use Node as a backend so the object style suits me.
• kureikain 9y ago
  Yes, Recently I read about Postgres 10 release. Almost all of the features of that are available in MongoDB too. 4 or 5 years ago, MongoDB was bad. But nowsaday the landscape was changed, and I would say MongoDB is quite decent to work with now. It's the easiest database to manage, compare with MySQl, PostgreSQL, ElasticSearch.
• GenericsMotors 9y ago
  > Bringing a database to the market with a completely different paradigm Ah yes, the "toss your data over the fence and hope for the best" paradigm. Truly groundbreaking.
• rdslw 9y ago
  I don't buy "creating a billion-dollar business". Ive read a Bloomberg story on the IPO and saw there two hilarious sequences "MongoDB has 4,300 paying customers. MongoDB employs 820 people in 29 offices" - that does not compute (for me) so I started analyzing their financial report (btw funny is nobody in whole HN discussion quoted numbers from the report so far, but a lot of 'im buying their stock' talks here). In the report, scroll to the bottom where they put some cream: they show for last year 91m rev from subscriptions plus 10m from services. While at the same time they show operating LOSS of 85 millions (due to cost, people, marketing, sales, services etc). Khem khem, I know they are growing (holy world) but no, that does not compute. Of course it is just mine opinion, and looking on the IPO results, rather unpopular one :) but I will stand by it. Especially in next 3 years. Caveat emptor. I will short them soon.
  • throw98987 9y ago
    How can one short it efficiently?
    • icahnvalyou 9y ago
      Most online brokers don't have lending inventory available yet. TD won't let me short.
      • notyourday 9y ago
        Of course they don't. Settlement time is T+3. Unless you are MM, until the first IPO + 3 days no shares can be located. At T+3 it will go into hard to borrow list.
        • icahnvalyou 9y ago
          TIL
    • nailer 9y ago
      Outside the US, you can do OTC derivatives via Spread Betting. Eg, give me/take from me a pound for every point this stock moves for/against my bet. Most spread betting providers in the UK carry NASDAQ stocks. Note the downside is unlimited when you short via spread betting. Eg, there's no maximum value of a stock, so you might get proper f'd.