TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Why Did So Many Startups Choose MongoDB?

102 点作者 brakmic将近 8 年前

43 条评论

Daishiman将近 8 年前
The misplaced hype cycle is real.<p>10gen is <i>not</i> a company dedicated to databases, at least not if the initial code quality of MongoDB is a signal (and it should be, since if you know a thing or two about storage you wouldn&#x27;t take the compromises it initially did)<p>Unfortunately, many fresh graduates with no experience in storage decided to evaluate the technology based on its very visible merits, without considering that scalability is not really a top priority even in companies that have to &quot;scale&quot;, and that reliability trumps every other metric.<p>Mongo has failed spectacularly in being a reliable data store, and its scalability is mediocre, given that it&#x27;s a lot more about query planning, analytics and optimization than having out-of-the-box sharding.<p>This is one of those areas having some seniority does wonders. Storage concepts are not easy to grasp, and evaluating a database&#x27;s reliability takes much longer than most product cycles.
评论 #14712854 未加载
评论 #14712390 未加载
jasondc将近 8 年前
This post makes the assumption that MongoDB isn&#x27;t doing well based on Hacker News. MongoDB the company, and product, are doing extremely well (outside of anecdotal Hacker News posts), based on objective metrics like downloads, skills, jobs, and company revenue (and the company is nearing 900 employees on linkedin).<p>To put it another way, RethinkDB did extremely well on Hacker News. Twitter didn&#x27;t, if you remember all the negative posts (and still went public). There is little relation between success on Hacker News and company success.
评论 #14712382 未加载
评论 #14712339 未加载
评论 #14712586 未加载
评论 #14712472 未加载
评论 #14712525 未加载
评论 #14712599 未加载
评论 #14712408 未加载
joeblau将近 8 年前
Back in 2012 I worked at a startup and we had a few backend data stores (Vertica, Postgres, Redis, Big Table, MySQL, Cassandra, ElasticSearch, Hadoop).<p>When 10gen came along, they sold us an amazing vision. We were processing 500 million to billion social media messages a day and they sold us on this dream that we would have very fast writes, a cluster of 9 machines in master-slave-slave config for fail over. We wouldn&#x27;t have to write SQL anymore (which was actually funny to watch one of our engineers try to unlearn table denormalization).<p>At the end of the day, it was hype. I had to stay up during multiple 2012 debates for 5 hours and flip the Mongo databases because they kept crashing. The shard key they set up for us was slightly out of balance so the data distribution was 30-30-40 and every so often, that server processing 40% of our data would jump to 50% and then knock that server offline leaving the other 2 to split 50% of the work... knocking them offline. There were also tons of replication problems all traced to write locking. At the end of the day 10gen solved one problem, but our company traded that solution for other problems.<p>That experience taught me that you really need to understand what you&#x27;re trying to solve before picking a database. Mongo is great for some things and terrible for others. Knowing what I know now, I would have probably chosen Kafka.
评论 #14712757 未加载
评论 #14714031 未加载
评论 #14712987 未加载
评论 #14714258 未加载
ransom1538将近 8 年前
I have been paid by two companies to remove Mongo. One that was hosted at the Mongo HQ. (The mongo HQ guys are really nice). At small startups, things are on fire and people need answers quick. &quot;How many users tried this, how many times was feature x used,&quot; on and on. If it is in mysql, well i just setup a vpn and a read mysql access, done -- they can query away.<p>If it is all in mongo? Welp. How is your python? &quot;See there is this key, and you need to sum this -- OH and remember that this does.. Hmm, &quot;
nemild将近 8 年前
I wrote this series over several months and am happy to answer questions.<p>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&#x27;s marketing strategy and how it influenced uptake. Sign up here to be notified: <a href="http:&#x2F;&#x2F;eepurl.com&#x2F;cxs5Zr" rel="nofollow">http:&#x2F;&#x2F;eepurl.com&#x2F;cxs5Zr</a><p>As any reflective engineer, it&#x27;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.
manishsharan将近 8 年前
I think Enterprise folks do not appreciate the flexibility afforded by NoSQL . For my startup I started off on PostGres SQL with Hibernate and it worked great ... until we first met our paying customers. They needed data elements that I had not envisioned and so we ended up doing Schema updates.. again and again . Since we used ORM (hibernate), that also meant new hibernate code generation . After a while this became very tedious.<p>I have a background in enterprise s&#x2F;w development; we always lock down on most of our requirements before we start writing code. RDBMS is fantastic in this scenarios. In my startup, we build something light and show it to bunch of prospects and iterate. MongoDB fits this mode of s&#x2F;w development for us. Sure there are gotchas and other issues but they have not affected us yet.
评论 #14712917 未加载
评论 #14716031 未加载
评论 #14712929 未加载
logwriter将近 8 年前
You guys are discussing MongoDB from 2009. The database has evolved since then.<p>- There is a new replication protocol for replica sets, improving the election process.<p>- WiredTiger has been introduced and became the default storage engine.<p>- Journaling guarantees durability.<p>- Sharding architecture has changed. Config Servers are now deployed as Replica Sets and some of the tasks that used to be managed by mongos now are managed by the config servers.<p>- Storage efficiency has been added through compression.<p>- Security has been improved with encryption at rest.<p>- The aggregation framework has more options for BI.<p>- There are a variety of different indexes that can be created to improve query performance.<p>- and finally, stop saying MongoDB is schemaless because it is not. There is a schema in place and this schema is flexible enough to be polyform.<p>These are features available today in 3.4. You might have issues in the past, but if you really understand the newest architecture, you are capable of seeing how much MongoDB has grown since 2.4.
评论 #14716096 未加载
joshribakoff将近 8 年前
I use Mongo &amp; its been working great. Our data is not relational (imagine you were tasked with building &quot;Powerpoint&quot; on the web).<p>Compared to mysql I like that it has automatic failover out of the box. I can also just add new replica set members without having to stop the master or bring a slave offline to rsync it over.<p>With something like mysql I have to learn about &amp; choose between row based replication or statement based replication. I have to choose between binary logging or global transaction ID logging. With Mongo I just call rs.init() and rs.add() and it &quot;just works&quot;.<p>Perhaps I&#x27;m just not hitting the level of traffic where the problems begin to surface, or maybe postgres would be better... but its been great so far. No complaints. The only issue was de-normalized data getting out of sync due to bad coding in our app, which i do not blame Mongo for (and was simple to fix).
评论 #14713028 未加载
nevi-me将近 8 年前
Interesting article, and I look forward to the other 2 parts. This was well-researched and balanced.<p>MongoDB​ feels like a different product to what it was when the hype was high. The company, leadership and engineering quality certainly have changed.<p>Someone else commented about the HN bias, which we can&#x27;t deny exists.<p>I&#x27;ve been running an 1-member replica for as long as I could figure out how replicas work. So I&#x27;ve had my Mongo database running for the last 5 years. It&#x27;s met the sweet spot that I was looking for when I knew less than what I do today.<p>Even if one were to rubbish the product, it still has value as the company seems to be doing well (even with the negative sentiment and press). Mongo sometimes feels like how &quot;corporates&quot; (at least in the recent past) feel about open-source. Dealing with our SAS account at work, the sentiment used to be that open-source was a waste of our time. Open-source is brittle and slow, rather use Oracle, etc. SAP HANA will change your life, in-memory is hard, our &quot;appliances&quot; run on unsecular hardware ...<p>Those sentiments have changed over time, so we shouldn&#x27;t eternally write things off if they&#x27;re healthily maintained.<p>I look forward to mixing SQL and NoSQL well into my future. DocumentDB wouldn&#x27;t be what it is today if there was no Mongo . The SQL vs NoSQL flame wars get us nowhere to be frank.
dizzystar将近 8 年前
I think the short answer is the same today as it was back in those days. A person once put it to me simply: &quot;programmers are afraid of databases.&quot;<p>It was a perfect mixture of this unfounded fear with an advertised simple solution. Add the idea that there is no need for a DBA, encourage developers to see Mongo as a magic data storage and nothing more, and you have the perfect product for those who don&#x27;t feel the need to look deeper.<p>Startups seem more optimized to fast iteration and quick development. It seems to me that they chose Mongo because they prioritized iteration and ease-of-development over the hard-nosed style needed to use a relational database well.
评论 #14713649 未加载
siculars将近 8 年前
Mongo succeeded for three reasons:<p>1. Architecturally is was very familiar to traditional relational systems like MySQL. Meaning classical master&#x2F;slave, sharding and absolute consistency via locks.<p>2. Mongo&#x27;s rise coincided with the rise of NodeJS and continued on the success of Ruby on Rails.<p>3. Mongo has done a phenomenally fantastic job attracting developers with exceptional documentation and getting started materials.<p>These all combined into a perfect storm attracting legions of developers. Note that these things have absolutely nothing to do with the technical capabilities of Mongo as an actual database.
评论 #14712877 未加载
wyc将近 8 年前
MongoDB is an interesting database for sure. It seems that they made a deliberate product decision to optimize developer experience and ease of use over things like consistency and database joins. Frankly, I think it&#x27;s working pretty well for their business.<p>I don&#x27;t think there&#x27;s anything that should immediately preclude the use of MongoDB in a production environment. I personally wouldn&#x27;t use older versions of it as a single source of truth, but there are definitely some great use cases for it, such as allowing developers who only know JavaScript to write non-critical backend services.<p>People seem to forget that database consistency is not binary, but residing on a spectrum. Like any other trade-offs, you should carefully measure the costs and benefits for your particular situation before making a decision.
nasalgoat将近 8 年前
We chose it because the lead developer liked it, and when I did my research I didn&#x27;t find any glaring issues because it was too new.<p>The lead dev had never actually used it, but liked the idea of not having to come up with a schema and he really liked JSON as he was very familiar with it.<p>By the time we were done, we were easily one of the top 5 users of MongoDB at scale and it was responsible for 9 out of 10 of our outages due to various bugs or optimization issues.
have_faith将近 8 年前
I&#x27;m not a back-end dev strictly. I played with mongo on some side projects back when it was all hyped up. One thing that appealed to me was the on-boarding process for a non &quot;database guy&quot;. I got lots of small side projects up and running very quickly and the concepts made sense. Similar to jQuery being easy to understand and popular to newcomers but you later learn it isn&#x27;t always the best tool for the job.
diziet将近 8 年前
Any criticism of MongoDB that does not acknowledge WiredTiger and the plethora of positive changes that made MongoDB much, much better in the 3.0, 3.2 and 3.4 releases is criticism that is not fully thought out.<p>It&#x27;s like complaining getting graphic cards working because of drivers is difficult on Ubuntu, based on experience with linux in 2005.
评论 #14712678 未加载
评论 #14715205 未加载
评论 #14715206 未加载
felipeccastro将近 8 年前
It&#x27;s not just because of hype that teams choose Mongo. The flexibility of a schemaless db is pretty helpful in a startup scenario, where the requirements drastically change all the time.<p>Yes, migrations work for RDBMS too, but with Mongo you only write migrations for data changes, not schema changes - which means a lot less migrations.<p>The option of having documents with embedded objects&#x2F;lists makes it a pretty natural mapping to Domain Driven Design concepts, like aggregate roots + aggregates. One might even argue that while following DDD, it&#x27;s preferable to handle most rules at the application layer and use the database simply as a performant, low-maintenance storage service. I know some folks here might view this approach as a sin, but it works pretty well too, especially for smaller teams without a dedicated DBA.<p>Maybe it&#x27;s just me that haven&#x27;t ran large enough systems to find the kind of issues with mongo that people always rant about, idk. Honest question: considering all these advantages above (from a developer&#x27;s point of view), are there good reasons for choosing something like PostgreSQL over Mongo for typical business apps?
评论 #14713690 未加载
评论 #14713701 未加载
jondubois将近 8 年前
I still think MongoDB is a good database. Conceptually, It&#x27;s not as good as RethinkDB but it&#x27;s not too far off. It&#x27;s good to not have to deal with SQL and horrible ORMs anymore.<p>TBH, I&#x27;d rather write SQL directly rather than use an ORM though. I never want to use an ORM ever again. At least that&#x27;s one problem that MongoDB solved.
评论 #14712537 未加载
评论 #14712600 未加载
takeda将近 8 年前
Looking at the table from 10th Gen, I believe it is misleading, at least in relation to Edmunds. I worked there, and Oracle (which was the source of truth) was replaced by PostgreSQL.<p>Mongo did replace Oracle product but it was Oracle&#x27;s Coherence[1]. There wasn&#x27;t a concern of Mongo loosing data, because the data could be reloaded again from Postgres if it got lost.<p>I also heard that they were considering replacing Mongo with Postgres as well, but I do not know where this went.<p>I think 10th Gen is just good at generating hype. The migration was not because Mongo was better but because Oracle was expensive and not that much better from Open Source alternatives.<p>[1] <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Oracle_Coherence" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Oracle_Coherence</a>
rfehrmann将近 8 年前
We are also one of those companies that bought into the promise (or hype) in 2011 and gave MongoDB a spin. After some very successful tests, I had long conversations with my CTO on why we should deploy MongoDB in prod and make it our primary OLTP store. Yes, MongoDB had it&#x27;s challenges in 1.6 and it required some &quot;faith&quot;. But it&#x27;s 2017 now and MongoDB totally delivered on it’s vision, at least for us. Since 2012, that&#x27;s when we upgraded to 2.0, we had 10 min of total downtime. That&#x27;s 99.999% uptime in 5 years. Year after year, 99.999% uptime. And that 10 min is the total for scheduled (btw, we don&#x27;t have scheduled downtime for our MongoDB clusters since there is no need for that) and un-scheduled downtime. We never take the service down. We perform all maintenance operations during regular business hours with no impact to end-users at all. So much about reliability! MongoDB as a product has bugs. What a surprise, what software product doesn&#x27;t. But it&#x27;s about you community (we are running the community edition) supports the product. We recently discovered an issue as well causing the primary to crash. As designed, another member in the repl set took over and there was no downtime at all. Even though we don&#x27;t have a support contract, the issue was acknowledged by MongoDB in hours and fixed in a couple of days. I wish we had that type of support for products where we do have a support contract! And last but not least, if you can&#x27;t figure out how to successfully use MongoDB, for god sake, take some free training classes on MongoDB University. MongoDB might not be a good fit for every use-case, but it&#x27;s already an awesome platform for an incredible number of applications. Polyglot environments is the keyword here. SQL has it’s advantages and disadvantages and so does NoSQL. Use the best tool for the problem. One size fits all doesn&#x27;t work anymore and MongoDB is clearly the best and most popular document store on the market. And even better, other platforms like postgres have acknowledged that the idea of storing JSON has its merits and have implemented its own version of that idea. However, IMO, if your use-case is a good fit for a document store, use MongoDB. We have done so and couldn&#x27;t be happier with that decision.
jszymborski将近 8 年前
What NoSQL databases are people using today when they need something ACID compliant? CouchDB?
评论 #14712538 未加载
chx将近 8 年前
For us, the reason to run with MongoDB in 2009 were twofold: a) for one of our products which was consuming the Twitter gardenhose, unverified writes were a blessing. We got away with a single dedicated server running mongodb (and it was not a particularly expensive server). I would need to do serious research again whether there&#x27;s a better solution for this today. It was using Stanford NLP to highlight breaking news before anyone realized. We never got a single subscriber because every newsdesk that saw it wanted to acquire us immediately LOL. Eventually one did. b) For another, the ability to store and index complex documents which in SQL would&#x27;ve needed JOINs and you couldn&#x27;t index across JOINs at least in MySQL and our previous experience in PostgreSQL vs MySQL support didn&#x27;t favor PostgreSQL at the time at all. It worked -- although it didn&#x27;t have a journal back then. We were ready for a failure but the failure never came. The landscape today is much different with PostgreSQL and MySQL and SQLite all embracing JSON storage and indexing on expressions are there for all three.
jsherard将近 8 年前
I find it difficult to seriously address comments to this thread. People still referencing 10gen and talking about data points from 5-10 years ago (2009, 2012, 2013).<p>You do realize it&#x27;s 2017 now, right? Many things have changed in MongoDB (and in the IT world in general) during the last 5 years. MongoDB is a mature, established, full-featured database - recognized by Gartner as a &quot;challenger&quot; to more established RDBMS vendors like Oracle and Microsoft.<p><a href="http:&#x2F;&#x2F;bit.ly&#x2F;2uP3Obi" rel="nofollow">http:&#x2F;&#x2F;bit.ly&#x2F;2uP3Obi</a><p>MongoDB has many built in features that are extremely attractive for building modern applications. Built in HA &amp; DR, horizontal scalability, multiple storage engines, rich indexing and query capabilities, enhanced BI features in aggregation framework, and many more...
alberth将近 8 年前
Not to sound flippant but the reason why so many startups choose mongodb is because the problems they are working on are better suited to be addressed with a document-oriented database than relational database.<p>And at the time, most of the mindshare is&#x2F;was with mongodb for document-oriented technology.
评论 #14716101 未加载
cbsmith将近 8 年前
Come on, we all know why: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=b2F-DItXtZs&amp;list=PLmGAf2A36COcfSrQfNkeocctpfmG1glwT" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=b2F-DItXtZs&amp;list=PLmGAf2A36C...</a>
评论 #14712571 未加载
评论 #14712895 未加载
xmatos将近 8 年前
Hype and lack of critical thinking abolutely had their role, but mostly because it&#x27;s so much easier than a relational db.<p>Relational db&#x27;s are hard. You have schemas and query planners and the truth is, you have to take care of every single query. Every query counts.<p>The same query can take 30 seconds, or 30 milliseconds to run, depending on it using an index or not. You think it&#x27;s ok for it to take 2 or 3 seconds, until it hits production and halts the server.<p>Mongo doesn&#x27;t have any of that. Just load and dump json back and forth, which is perfect for fast prototyping.<p>Who cares about data integrity or technical debt?
评论 #14712773 未加载
mbesto将近 8 年前
I&#x27;ve assessed a fair number of companies who use Mongo in some way or another and the I always ask the rationale for the decision. Surprise surprise, it&#x27;s usually &quot;we chose it because it was easy to start with&quot;.<p>My favorite recent one was a company that had to persist their Mongo database into AzureSQL (nightly job) so they could then push it to Good Data for analytics. They could have very easily used SQL Server and pushed directly from there to Good Data. And yes the company admitted that was the case.
评论 #14712761 未加载
bastijn将近 8 年前
Obligatory read when talking MongoDB <a href="https:&#x2F;&#x2F;aphyr.com&#x2F;posts&#x2F;322-jepsen-mongodb-stale-reads" rel="nofollow">https:&#x2F;&#x2F;aphyr.com&#x2F;posts&#x2F;322-jepsen-mongodb-stale-reads</a> and follow-up <a href="https:&#x2F;&#x2F;jepsen.io&#x2F;analyses&#x2F;mongodb-3-4-0-rc3" rel="nofollow">https:&#x2F;&#x2F;jepsen.io&#x2F;analyses&#x2F;mongodb-3-4-0-rc3</a>.<p>Ensured me to never use this for production scenarios. No matter how &#x27;hyped&#x27; or &#x27;convenient&#x27; it is. Yaiks.
virmundi将近 8 年前
As a person who just recently turned down an offer to write an ArangoDB book, Mongo is not worth it. I think most needs are met between Arango and PostgreSQL. Arango provides a scalable NoSQL option over PostgreSQL (let&#x27;s see what version 10 holds). PostgreSQL provides a solid, efficient SQL solution.<p>Mongo provides no benefits of transactions or solid design. If you want either, look to Arango or PostgreSQL.
JustSomeNobody将近 8 年前
There were so many blog posts about how MongoDB was the future and SQL&#x2F;relational dbs were the past.<p>I wish someone would collect all the hyped up tech blog posts so that we always have a reference to be able to say, &quot;see what hype does?&quot; Sadly, I think it would only increase the number of devs saying, &quot;Not this time, it&#x27;s different.&quot;
ivm将近 8 年前
Our team had little experience with backends in 2013 and a fear that it will be hard to scale game servers in case of success (players hate lags and downtimes).<p>So we followed the hype of Node.js and MongoDB because everybody was saying how it&#x27;s easy to scale them compared to the established tech.
smileysteve将近 8 年前
Similar questions can be asked<p>&gt; Why do so many developers use map&#x2F;reduce instead of the database for select, pluck, math?<p>&gt; Why do so many developers use length instead of counting sql?<p>The learning curve was easy, it was very compatible with javascript, it was very easy to install, it had similar features to sql lite.
namlem将近 8 年前
Because they have great docs. At least that&#x27;s why I chose them for my (now defunct) startup back in 2013. I wasn&#x27;t familiar with databases and their docs were extremely approachable and easy to understand and navigate, with lots of useful examples.
dyeje将近 8 年前
Reminds me of the keynote DHH gave at RailsConf this year. Despite the stories that we like to tell ourselves about picking the right tool for the job, we&#x27;re just as prone to chasing the shiny new thing as all the other humans.
评论 #14712983 未加载
Osmium将近 8 年前
I&#x27;ve seen a few comments mention RethinkDB ... what are the advantages over MongoDB?<p>I can read their feature page but as someone who isn&#x27;t an expert, I&#x27;m not sure what&#x27;s marketing hype and what&#x27;s genuine advantage.
评论 #14713328 未加载
评论 #14713355 未加载
nir将近 8 年前
Marketing aside, MongoDB is just really easy to pick up and use. In a small project, its weaknesses don&#x27;t really show up (at least in my limited experience), if it gets big you often end up rebuilding anyway.
andred14将近 8 年前
Anyone with average to more DB experience knows there is no one-stop shop. DBs are about trade-offs and we need to choose the right ones for our application(s)
stevecalifornia将近 8 年前
Knowledge does not equal wisdom. Perhaps it was young folks with lots of knowledge didn&#x27;t see the wisdom in using battle-hardened, boring technology.
评论 #14713009 未加载
andred14将近 8 年前
Anyone with proper unbiased DB knowledge knows without trying or reading anything that it is hype. DBs are all about trade-offs you can&#x27;t have it all
ahallock将近 8 年前
Marketing &amp; ease of use (for example, if you try to insert into a collection that does not exist, it&#x27;s automatically created for you).
Tokkemon将近 8 年前
Because it&#x27;s <i>not</i> MySql. &quot;We can&#x27;t use our <i>dad&#x27;s</i> database!&quot;
exabrial将近 8 年前
Really good marketing, mongo&#x27;s pitch was &quot;use this if you want to be Innovative&quot;
niahmiah将近 8 年前
to avoid schema migrations
评论 #14712968 未加载
jaraco将近 8 年前
I&#x27;d wanted to lift the burden of writing ORM layers and dealing with relational algebra and focus on persisting my intrinsic application models. I&#x27;d studied XML and other semi-structured web data at the graduate level, but was frustrated there wasn&#x27;t a technology that was meeting that need. Companies like Microsoft and Oracle were adding XML functionality to their databases, but because it was bolted on an already constrained structure, it failed to address the mangling that relational structures impose.<p>I saw a demo of MongoDB in 2010 and was thoroughly impressed. The developer experience out of the box was exquisite. During a 1 hour presentation, I was able to download the binary, connect to the shell, create records in a familiar form (JSON), query the data from my preferred language, and all within a often second-class platform, Windows.<p>There was a certain _joy_ to using MongoDB, but I had my doubts, too. If this form of database interaction was so easy and fun to use, what was the catch?<p>Well, the catch was that MongoDB was re-thinking the issue from the ground up, re-envisioning the way we work with data, in an attempt to transcend the inertia that held back existing offerings.<p>When I started working with MongoDB, it felt like the same transcendence I experienced moving from C++ to Python in 1998--the approach was simpler, more intuitive, and powerful.<p>Sure, there were some growing pains. The concept came first without acknowledged writes or even journaling. Replication came in stages. Sharding came later.<p>But our operation was able to go from startup-scale to a global enterprise-scale operation backed by MongoDB, performing admirably, and giving developers the ability to rapidly innovate in a low-impedance environment. We&#x27;ve since developed dozens of applications against MongoDB.<p>I&#x27;ve considered emergent competing offerings like PostgreSQL with its JSON store, but when I did a few years ago, they were still dramatically behind in replication and sharding support, requiring extensive administration for aspects that MongoDB handled out of the box.<p>And in the meantime, MongoDB has continued to innovate, bringing in pluggable storage backends, advancing the query engine and aggregation framework, adding native geo-location support, and formalizing the concept of shard zones (a key feature for global scalability). And with Atlas, they&#x27;ve made server administration a near zero-cost proposition.<p>I&#x27;m a fan because when it comes to boots-on-the-ground experience, I see nothing else in the industry that even comes close. The most pressing deficiencies have been addressed and without compromising the key innovations. As a developer and technology leader, I choose MongoDB as my default database and would only consider a traditional database if the use case was intrinsically highly constrained and tabular in nature.