16 ms·

I think you're asking the wrong question. The question should be: How did MongoDB become so successful? IMO, the reason is that newer developers faced the choi

by csytan 8y ago

I think you're asking the wrong question. The question should be: How did MongoDB become so successful? IMO, the reason is that newer developers faced the choice of learning SQL or learning to use something with a Javascript API. MongoDB was the natural choice because they excelled at being accessible to devs who were already familiar with Javascript and JSON. Not only that, their marketing/outreach efforts were also aimed at younger developers. When was the last time you saw a Postgres rep at a college tech event?

nemild 8y ago
I think you'll enjoy the series then, I spent several months investigating and made the same point about JSON and the Javascript-like CLI (plus great Node support, plus savvy marketing). For example: > 10gen's key contributions to databases — and to our industry — was their laser focus on four critical things: onboarding, usability, libraries and support. For startup teams, these were important factors in choosing MongoDB — and a key reason for its powerful word of mouth. Startup Engineers and Our Mistakes with MongoDB https://www.nemil.com/mongo/2.html https://www.nemil.com/mongo/2.html The Marketing Behind MongoDB https://www.nemil.com/mongo/3.html https://www.nemil.com/mongo/3.html
- RobertKerans 8y ago
  Halfway into part two, this is very good so far. Thank you for the effort you put in (it really does show throughout).
acjohnson55 8y ago
> When was the last time you saw a Postgres rep at a college tech event? Is a Postgres rep a thing?
- WJW 8y ago
  That's the point.
- twirlip 8y ago
  I remember a hyperbolic readme or other such txt file for Postgres in the far-away long-ago time when everyone was on Slashdot. The author had written one of the most enthusiastic lovenotes to software I'd ever read, and that includes Stephenson's "In The Beginning Was The Commandline." It was a Thomas Wolfe level of ejaculatory keenness. I'd love to read it again if anyone else knows where I can find the file. So, even if there aren't actual Postgres reps, there are most assuredly evangelists.
OJFord 8y ago
Absolutely - if you don't know SQL and you do know JSON, postgres looks scary and Mongo looks familiar.
- threeseed 8y ago
  You make it sound like learning SQL is like learning Assembler. It's not that hard. And ORMs exist in every language to abstract it all away. PostgreSQL looks scary because it is a swiss army knife. It has a million different features and data structures. MongoDB does only one thing.
  - zapzupnz 8y ago
    > You make it sound like learning SQL is like learning Assembler It's not that learning SQL is hard. It's that people are inherently lazy. "Learn another thing on top of the thing it already took me a couple of years to learn? No thanks." You seem like the kind of person ready and willing to learn the right tool for the job. From my experience a few years ago on an accredit computing course that covered database admin and programming, this attitude is not representative of most of the software engineering students //unless// there's a specific assignment that requires particular knowledge. Cs get degrees. And for plenty of developers out there, knowing one language (not even particularly well) gets jobs.
    - rabidrat 8y ago
      I think what happens (and I have this attitude too) is that "learning" SQL takes a weekend...but then you know you'll wind up having to spend a lot longer learning the patterns of the language, and the nuances of the specific dialect, and which of the integration tools will work well with your workflow and pipeline. So while "sure I'll just learn SQL" is great for a personal or school project, when you've got to get something done next week, it's better to take maximal advantage of the tools/skills/workflow that you already have. IOW, it's not just laziness, it's a kind of professional conservatism. which is partly what gets older engineers stuck in a particular mindset, but it's also a very effective learned skill. The opposite is being a magpie developer, which results in things like MongoDB taking off :)
threeseed 8y ago
None of this makes sense. ORMs have existed for decades so developers can use a SQL database just fine without knowing the language. So it's definitely not this. It's more likely because Mongo is (a) is extremely fast, (b) the easiest database to manage and (c) has a flexible schema which aligns better with dynamic languages which are more popular amongst younger developers.
- Something1234 8y ago
  To use an ORM and not get crap performance you still need to understand sql, and what is happening under the hood.
- paulie_a 8y ago
  Postgres is faster at json than mongo. Also the pipeline query strategy of mongo is terrible to deal with. A schema should not be flexible. Now I have to write a bunch of code to handle things that should have been enforced by the database. Postgres is incredibly easy to manage with actual default security. I know the mongo tutorial says to not run the default configuration, then why is it the default configuration. It's so easy to manage anyone can take it over for ransom. Mongo literally has no upside vs postgres.
golemiprague 8y ago
Not really, learning SQL is not harder than learning all the mongo query language, maybe even simpler. Sometimes you just want to try something new, especially in startups where the "best tool for the job" haven't revealed itself yet. Then you are just continuing with whatever you got because migration is too tiresome and it is kind of working. Then you know both SQL and mongo but you got a very extensive boilerplate ready for your next project so use mongo again. Until you got enough time to play with a relational again and you either migrate or build a new project based on it. Then you write a blog.
quietbritishjim 8y ago
> IMO, the reason is that newer developers faced the choice of learning SQL or learning to use something with a Javascript API. The thing I dislike about this type of comment – although I now notice yours doesn't explicitly say this – is the implication that devs don't like SQL because they're lazy or stupid. Well, sometimes that is probably true! But there are some tasks where you need to build the query dynamically at run time, and for those tasks MongoDB's usual query API, or especially its aggregation pipeline API, are genuinely better than stitching together fragments of SQL in the form of text strings. Injection attacks and inserting commas (but not trailing commas) come to mind as obvious difficulties. For anyone not familiar, just look at how close to being a native Python API pymongo is: pipeline = [ {"$unwind": "$tags"}, {"$group": {"_id": "$tags", "count": {"$sum": 1}}}, {"$sort": SON([("count", -1), ("_id", -1)])} ] result_cursor = db.things.aggregate(pipeline) Of course you could write an SQL query that does this particular job and is probably clearer. But if you need to compose a bunch of operations arbitrarily at runtime then using dicts and lists like this is clearly better. Of course pipelines like this will typically be slow as hell because arbitrary queries, by their nature, cannot take advantage of indices. But sometimes that's OK. We do this in one of our products and it works great. With JSONB and replication enhancements, Postgres is close to wiping out all of MongoDB's advantages. I would love to see a more native-like API like Mongo's aggregation pipeline, even if it's just a wrapper for composing SQL strings. I think that would finish off the job.
- mattbreeden 8y ago
  > genuinely better than stitching together fragments of SQL in the form of text strings. Injection attacks and inserting commas (but not trailing commas) come to mind as obvious difficulties. You're using the Pymongo library as an example. Someone can just as easily use SQLAlchemy and not have to worry about those things.
- funkaster 8y ago
  Well... you can also use a modern ORM. I think "stitching ... text strings" is definitively not the way to go when interfacing a SQL database. My go-to ORM is Sequel[1]. I think their API is one of the best I've seen: you can choose to use models, but you can also work directly with "datasets" (tables or views, or queries) and compose them as you like. It's really powerful and simple. [1]: http://sequel.jeremyevans.net/ http://sequel.jeremyevans.net/
inferiorhuman 8y ago
> I think you're asking the wrong question. The question should be: How did MongoDB become so successful? Marketing, marketing, and more marketing. Mongo was written by a couple of adtech guys. > Not only that, their marketing/outreach efforts were also aimed at younger developers. When was the last time you saw a Postgres rep at a college tech event? I remember being underwhelmed by two things at the one MongoConf I went to earlier this decade: 1.) My immediate boss was an unfathomable creep who was there mostly to pick up women 2.) Mongo was focused on how to work around the problems (e.g. aggregate framework) rather than how to solve them. I can't recall ever seeing a Postgres rep, but I can recall having worked out a PostGIS bug with a fantastically tight feedback loop. The Postgres documentation and community are nothing short of amazing. Meanwhile with Mongo I watched as jawdropping bugs languished. IDGAF what the reps say, anyone with even a few years experience should've been able to see through the bullshit that Mongo/10gen was/is selling.
cmrdporcupine 8y ago
From my POV the rise of 'NoSQL' some years back was tied into a number of things: - Misunderstanding by most developers of the relational model (I heard a lot of blathering about 'tabular data', which is missing the point entirely). - The awkwardness and mismatchiness of object-relational mappers -- and the insistence of most web frameworks on object-oriented modeling. - The fact that Amazon & Google etc. make/made heavy use of distributed key-value stores with relatively unstructured data in order to scale -- and everyone seemed to think they needed to scale at that level. (Worth pointing out that since then Google & Amazon have been able to roll out data stores that scale but use something closer to the relational model). This despite the fact that many of the hip NoSQL solutions didn't even have a reasonable distribution story. - Simple trending. NoSQL was cool. Mongo had a 'cool' sheen by nature of the demographic that was working there, the marketing of the company itself. I remember going to a Mongo meet-up in NYC back in 2010 or so, because some people in the company I was at at the time (ad-tech) were interested in it. We walked away skeptical and convinced it was more cargo-cult than solution. I'm _very_ glad the pendulum is swinging back and that Postgres (which I've pretty much always been an advocate of in my 15-20 year career) is now seeing something of a surge of use.
bcoughlan 8y ago
> Not only that, their marketing/outreach efforts were also aimed at younger developers. I do remember a lot of MongoDB t-shirts, cups and pens around every office I was in around 2011-2013. When I would ask they would tell me that a MongoDB developer flew halfway across the world to give them all a workshop on it.
k_bx 8y ago
> The question should be: How did MongoDB become so successful? Ability to store Algebraic Data Types and values with lists without a hassle of creating a ton of tables and JOINs. Postgres added JSON support since, plus there are now things like TimescaleDB, which didn't exist previously.

by csytan 8y ago

nemild 8y ago

I think you'll enjoy the series then, I spent several months investigating and made the same point about JSON and the Javascript-like CLI (plus great Node support, plus savvy marketing). For example: > 10gen's key contributions to databases — and to our industry — was their laser focus on four critical things: onboarding, usability, libraries and support. For startup teams, these were important factors in choosing MongoDB — and a key reason for its powerful word of mouth. Startup Engineers and Our Mistakes with MongoDB https://www.nemil.com/mongo/2.html https://www.nemil.com/mongo/2.html The Marketing Behind MongoDB https://www.nemil.com/mongo/3.html https://www.nemil.com/mongo/3.html

RobertKerans 8y ago
Halfway into part two, this is very good so far. Thank you for the effort you put in (it really does show throughout).

acjohnson55 8y ago

> When was the last time you saw a Postgres rep at a college tech event? Is a Postgres rep a thing?

WJW 8y ago
That's the point.
twirlip 8y ago
I remember a hyperbolic readme or other such txt file for Postgres in the far-away long-ago time when everyone was on Slashdot. The author had written one of the most enthusiastic lovenotes to software I'd ever read, and that includes Stephenson's "In The Beginning Was The Commandline." It was a Thomas Wolfe level of ejaculatory keenness. I'd love to read it again if anyone else knows where I can find the file. So, even if there aren't actual Postgres reps, there are most assuredly evangelists.

OJFord 8y ago

Absolutely - if you don't know SQL and you do know JSON, postgres looks scary and Mongo looks familiar.

threeseed 8y ago
You make it sound like learning SQL is like learning Assembler. It's not that hard. And ORMs exist in every language to abstract it all away. PostgreSQL looks scary because it is a swiss army knife. It has a million different features and data structures. MongoDB does only one thing.
- zapzupnz 8y ago
  > You make it sound like learning SQL is like learning Assembler It's not that learning SQL is hard. It's that people are inherently lazy. "Learn another thing on top of the thing it already took me a couple of years to learn? No thanks." You seem like the kind of person ready and willing to learn the right tool for the job. From my experience a few years ago on an accredit computing course that covered database admin and programming, this attitude is not representative of most of the software engineering students //unless// there's a specific assignment that requires particular knowledge. Cs get degrees. And for plenty of developers out there, knowing one language (not even particularly well) gets jobs.
  - rabidrat 8y ago
    I think what happens (and I have this attitude too) is that "learning" SQL takes a weekend...but then you know you'll wind up having to spend a lot longer learning the patterns of the language, and the nuances of the specific dialect, and which of the integration tools will work well with your workflow and pipeline. So while "sure I'll just learn SQL" is great for a personal or school project, when you've got to get something done next week, it's better to take maximal advantage of the tools/skills/workflow that you already have. IOW, it's not just laziness, it's a kind of professional conservatism. which is partly what gets older engineers stuck in a particular mindset, but it's also a very effective learned skill. The opposite is being a magpie developer, which results in things like MongoDB taking off :)

threeseed 8y ago

None of this makes sense. ORMs have existed for decades so developers can use a SQL database just fine without knowing the language. So it's definitely not this. It's more likely because Mongo is (a) is extremely fast, (b) the easiest database to manage and (c) has a flexible schema which aligns better with dynamic languages which are more popular amongst younger developers.

Something1234 8y ago
To use an ORM and not get crap performance you still need to understand sql, and what is happening under the hood.
paulie_a 8y ago
Postgres is faster at json than mongo. Also the pipeline query strategy of mongo is terrible to deal with. A schema should not be flexible. Now I have to write a bunch of code to handle things that should have been enforced by the database. Postgres is incredibly easy to manage with actual default security. I know the mongo tutorial says to not run the default configuration, then why is it the default configuration. It's so easy to manage anyone can take it over for ransom. Mongo literally has no upside vs postgres.

golemiprague 8y ago

Not really, learning SQL is not harder than learning all the mongo query language, maybe even simpler. Sometimes you just want to try something new, especially in startups where the "best tool for the job" haven't revealed itself yet. Then you are just continuing with whatever you got because migration is too tiresome and it is kind of working. Then you know both SQL and mongo but you got a very extensive boilerplate ready for your next project so use mongo again. Until you got enough time to play with a relational again and you either migrate or build a new project based on it. Then you write a blog.

quietbritishjim 8y ago

> IMO, the reason is that newer developers faced the choice of learning SQL or learning to use something with a Javascript API. The thing I dislike about this type of comment – although I now notice yours doesn't explicitly say this – is the implication that devs don't like SQL because they're lazy or stupid. Well, sometimes that is probably true! But there are some tasks where you need to build the query dynamically at run time, and for those tasks MongoDB's usual query API, or especially its aggregation pipeline API, are genuinely better than stitching together fragments of SQL in the form of text strings. Injection attacks and inserting commas (but not trailing commas) come to mind as obvious difficulties. For anyone not familiar, just look at how close to being a native Python API pymongo is: pipeline = [ {"$unwind": "$tags"}, {"$group": {"_id": "$tags", "count": {"$sum": 1}}}, {"$sort": SON([("count", -1), ("_id", -1)])} ] result_cursor = db.things.aggregate(pipeline) Of course you could write an SQL query that does this particular job and is probably clearer. But if you need to compose a bunch of operations arbitrarily at runtime then using dicts and lists like this is clearly better. Of course pipelines like this will typically be slow as hell because arbitrary queries, by their nature, cannot take advantage of indices. But sometimes that's OK. We do this in one of our products and it works great. With JSONB and replication enhancements, Postgres is close to wiping out all of MongoDB's advantages. I would love to see a more native-like API like Mongo's aggregation pipeline, even if it's just a wrapper for composing SQL strings. I think that would finish off the job.

mattbreeden 8y ago
> genuinely better than stitching together fragments of SQL in the form of text strings. Injection attacks and inserting commas (but not trailing commas) come to mind as obvious difficulties. You're using the Pymongo library as an example. Someone can just as easily use SQLAlchemy and not have to worry about those things.
funkaster 8y ago
Well... you can also use a modern ORM. I think "stitching ... text strings" is definitively not the way to go when interfacing a SQL database. My go-to ORM is Sequel[1]. I think their API is one of the best I've seen: you can choose to use models, but you can also work directly with "datasets" (tables or views, or queries) and compose them as you like. It's really powerful and simple. [1]: http://sequel.jeremyevans.net/ http://sequel.jeremyevans.net/

inferiorhuman 8y ago

> I think you're asking the wrong question. The question should be: How did MongoDB become so successful? Marketing, marketing, and more marketing. Mongo was written by a couple of adtech guys. > Not only that, their marketing/outreach efforts were also aimed at younger developers. When was the last time you saw a Postgres rep at a college tech event? I remember being underwhelmed by two things at the one MongoConf I went to earlier this decade: 1.) My immediate boss was an unfathomable creep who was there mostly to pick up women 2.) Mongo was focused on how to work around the problems (e.g. aggregate framework) rather than how to solve them. I can't recall ever seeing a Postgres rep, but I can recall having worked out a PostGIS bug with a fantastically tight feedback loop. The Postgres documentation and community are nothing short of amazing. Meanwhile with Mongo I watched as jawdropping bugs languished. IDGAF what the reps say, anyone with even a few years experience should've been able to see through the bullshit that Mongo/10gen was/is selling.

cmrdporcupine 8y ago

From my POV the rise of 'NoSQL' some years back was tied into a number of things: - Misunderstanding by most developers of the relational model (I heard a lot of blathering about 'tabular data', which is missing the point entirely). - The awkwardness and mismatchiness of object-relational mappers -- and the insistence of most web frameworks on object-oriented modeling. - The fact that Amazon & Google etc. make/made heavy use of distributed key-value stores with relatively unstructured data in order to scale -- and everyone seemed to think they needed to scale at that level. (Worth pointing out that since then Google & Amazon have been able to roll out data stores that scale but use something closer to the relational model). This despite the fact that many of the hip NoSQL solutions didn't even have a reasonable distribution story. - Simple trending. NoSQL was cool. Mongo had a 'cool' sheen by nature of the demographic that was working there, the marketing of the company itself. I remember going to a Mongo meet-up in NYC back in 2010 or so, because some people in the company I was at at the time (ad-tech) were interested in it. We walked away skeptical and convinced it was more cargo-cult than solution. I'm _very_ glad the pendulum is swinging back and that Postgres (which I've pretty much always been an advocate of in my 15-20 year career) is now seeing something of a surge of use.

bcoughlan 8y ago

> Not only that, their marketing/outreach efforts were also aimed at younger developers. I do remember a lot of MongoDB t-shirts, cups and pens around every office I was in around 2011-2013. When I would ask they would tell me that a MongoDB developer flew halfway across the world to give them all a workshop on it.

k_bx 8y ago

> The question should be: How did MongoDB become so successful? Ability to store Algebraic Data Types and values with lists without a hassle of creating a ton of tables and JOINs. Postgres added JSON support since, plus there are now things like TimescaleDB, which didn't exist previously.