6 ms·

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 n

• 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.
                • jsjohnst 9y ago
                  > Next time, just say "I'd rather quit than work with MongoDB again", and you won't have this problem. Fair point... “I would quit rather than work with MongoDB again” is more accurate, but still encapsulates your point. The point I was trying to make earlier and did in a way overly dramatic for you is that I’d never take a tech job again if it meant I had to use Mongo.
            • pessimizer 9y ago
      • Thaxll 9y ago
        lol, the things you read on HN, very entertaining.
    • erik_seaberg 9y ago
      Maybe they haven't noticed? I've seen databases fail in ways that take a long time to detect on accident, if you don't have a source of truth to sanity check against.
      • bsaul 9y ago
        maybe mongo is the db of failed products. Perfect until you really need a database. The high valuation could be an index of the number of failing products happily using the tech :)
• 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.