Why Did So Many Startups Choose MongoDB?

That Slack post is terrible. I can't believe they would site concurrency as a strength of PHP...."Asynchronously curl’ing to localhost (or even another web server) provides a shared-nothing, copy-in/copy-out way of exploiting parallelism." I almost have to wonder if this is satire

I wrote this series over several months and am happy to answer questions.

Part 2 will dive into the benefits of Mongo along with the mistakes that some teams made with Mongo. Part 3 will dig into Mongo's marketing strategy and how it influenced uptake. Sign up here to be notified: http://eepurl.com/cxs5Zr

As any reflective engineer, it's important for me to provide a thoughtful perspective backed by evidence. This can be a fraught discussion and I personally know teams that truly value Mongo, and other teams that had tremendous issues. I want to provide color about the early years of Mongo (not today). My key point is that as engineers, we have to get beyond hype, thinking critically and choosing the right tool for the job.

It isn't an age thing. There are mid-life engineers where I work who are constantly trying to force the latest fad in tech into our engineering organization.

Of course I don't know your product, but when I imagine Powerpoint-as-a service, do users not relate to decks which relate to slides which relate to the content on those slides? Content itself of course would probably be a pretty flexible tree structure.

An app full of queries like "Get me all the content of slide Y of deck XXXX... or don't if the current user YYY doesn't have access to that" would make me itching for indices and foreign constraints across what definitely feel like relations to me.

And for the non-relational content blobs, Postgres's partial indices + indexes on expressions would make some fairly intricate reports like "since we launched the image embedding feature, per week, what percent of created or modified slides contain images", "who are the top 10 users in terms of edits to content tree items, and what subscription level do they have" pretty neat and fast.

If you're in early stages such that you don't want to hire or acquire DBA skills, you're probably well served by offloading replication/backup/verification (which are all very possible with RDBMS) to e.g. AWS's RDS product.

HA is important, is covered by replication+failover. Periodic backups are important, are covered by a export+rotate schedule. Point-in-time restores are important, are covered by storing replication logs. All are covered by a managed RDBMS, so you need to know what they are and how they work, but not implement or manage them. Most of the NoSQL deployments I've seen just rely on the out-of-the-box replication, and get HA but that's it. The engineers I've seen that don't want to understand the simple high-level ramifications-to-developers of RDBMS replication don't want to understand ramifications-to-developers about their NoSQL replication either, and they take a risk of encountering those ramifications needlessly unforeseen.

As the data grows, yeah, maybe you'll eventually hit technical or economical limits that mean you'll want to manage your own RDBMS with an application-tuned replication and sharding scheme, so you'll want to hire or train at that point -- but there's huge huge room to play within the economic and technical characteristics of modern managed cloud RDBMS-as-a-service for any app that has a hint of a business model, given that we measure the cost of such services in cents per billion unit-hours.

It's certainly nice when talking in developer circles, but no, public perception is not the primary reason — it's more of a bonus :)

I really enjoy some of the more flexible syntax and design choices present in some other languages. It also help that various job requirements over the year have required that I build a broader skillset. Finally, the growth I've experienced by stepping outside my comfort zone the past few years is probably the best benefit, which is a good experience regardless of which language(s) you start with.

In the end, however, as we both know, most decisions in software development are an exercise in managing tradeoffs. I guess the core of my argument is that, in the past few years, PHP has done a great job at improving its balance of tradeoffs.