Kudos on a magnificent post, and of course commiserations.

One thing resonated strongly with me. When we started out many years ago someone said to me that the worst market you could go after was to target developers. Case in point - every developer who's ever put up a web site has built or thought about building a CMS. There must be thousands upon thousands of them, virtually all with a price of $0. Who would want to sell a CMS product?

We heeded that advice and I often reflect on it during the sales process when we have the "lets just run your offering past the IT team" meeting. So often, the line of questioning from the smartypants dudes in the room is all about tripping us up, finding our weak spot (I'm a techy so I get it - I think like this myself).

The best you can normally come out of that meeting with is grudging acceptance from IT that a SaaS solution should be OK, given that the business is in a rush and all, and given that IT has other priorities. (To be fair its much less like this these days, but a few years ago this was the norm).

By contrast, showing your product to a business person is a breath of fresh air. They don't want to build it themselves, they don't really care what's under the bonnet, they just want good, quick solutions to their actual problems, so they can go home at night and sit down to Netflix. HR people (our target market) are even nicer.

What's more those business people want to pay for your solution. A quick way to kill the deal is to joyously tell them "its free!". They need to understand how you get your buck at the end of the day. They'll never buy until they understand that. And the best (because its the simplest) answer is "we've got the best product, so we charge good money for it".

IT people try and "trip you up" because we've been burnt so many times in the past with systems that don't do what is promised by the sales people, don't integrate well and who stiff you during the implementation phase.

HR people are some of the worst because everything is super secret and they don't want to get IT involved, then they go and buy a system that lets you insert a carriage return into the phone number field and produces CSV files that don't have primary keys for data extracts.

It hurts because I lived it so many times. The "you can't understand", "it's complicated", "it's a HR thing" is such bullshit.

Everyone walks on eggshells around HR for "compliance" stuff. Anecdotally, I've not see a whole lot of compliant practices in the stuff HR wants. The high end HR solutions tend to enforce it, but there are always amazingly bad home grown tools sitting around to allow you to "pull a list of all our employees and all our data to a CSV" and then you find out the person converted that CSV to a google doc...(I've not seen anything that combined all these steps exactly this way, but I've seen each of these steps. The more legacy the tools, the worse)

And yet a bunch of them chose MongoDB (over something else, not just over RethinkDB.) Was there some point in time when it was the best option for a lot of people?

They were a fairly early entry into modern document databases. They offer sharding/mirroring, and have a really simple, relatively nice interface. In the end, they're a good (enough) fit for a lot of use cases. While RethinkDB imho is absolutely better, market share entropy counts for a lot. ElasticSearch is a similar product in the end, with lower consistency guarantees, that is another good fit for a lot of use cases. Cassandra (C*) is also a good fit for similar use cases, though more difficult to work with, it's also more tune-able to specific needs.

It really depends on what you need... Every non-sql database tends to sacrifice something for some performance gain... RethinkDB is as close as I've seen to one without sacrifice.

Yes, there was a point it was clearly the best option. Qualitative it was easy to understand. The mongo Cli looked exactly like MySQL. And it's single node performance was decent.

CouchDB was super slow. Cassandra was amazing but a bit confusing. MongoDB made sense and worked.

These anecdotes are gold

First, thanks for your candor in this.

If you're open to edits, the $200k revenue/employee rule of thumb really doesn't make a lot of sense when you're comparing your three alternate business models (Hosted Rethink, DBaaS Rethink and "Hey, maybe PaaS on top of Rethink?").

Like you, I thought it would be way too hard to run a service (my own company was encouraged to do so, and we shied away for it for the same reason you stated). However, having seen it now from the inside for GCE for nearly 4 years, I can say it's much easier to "service-ize" yourself than it is to have built a product people want. And moreover, the shell scripts and operations stuff really scales (effectively, the hosted DB offering is the binary plus a bit of bash, while the other offerings require yet more "not done before" software).

Even more surprisingly, this statement:

> Managed hosting is essentially running the database for people on AWS so they don't have to. The alternative to using these services is setting up the database on AWS yourself. That's a pain, but it isn't actually that hard. So there is a very hard cap on how much managed database hosting services can charge.

turns out to just not be true in practice. People pay us (Cloud SQL) and AWS (RDS) a surprising amount of money to run MySQL in a VM for them. It turns out that people really like outsourcing even a small amount of pain, but that we're (as engineers) easily blindsided to "Um, why would I pay you XX% over the raw VM price? You're just running some shell scripts for me". Little things like automatically updating to the latest version, configuration replication, etc. are things that nobody will bat at an eye at paying you for (I believe in the DB space in particular, it's because the overall cost of your DB is dwarfed by "All the rest", so it's a good trade of people time versus $$s).

I hope this doesn't come across as Monday-morning quarterbacking, but if I did mine over again I'd take the "Build a great piece of software, and even if it's open, service-ize it for folks". It's true that you're competing with the Cloud providers, and that it seems like you wouldn't really be able to get people to pay you for it (and it's not your core competency), but I think it's the best option for this flavor of infrastructure software moving forward.

> If you're open to edits, the $200k revenue/employee rule of thumb really doesn't make a lot of sense when you're comparing your three alternate business models

Sure, but for many venture funded companies and even large enterprises top-line is the top metric you're focused on. If you're in a growth industry it's about top line revenue, capturing market share, and cost of underlying bits will eventually come down.

> turns out to just not be true in practice. People pay us (Cloud SQL) and AWS (RDS) a surprising amount of money to run MySQL in a VM for them.

For infrastructure providers to "service-ize" you can set cost as a much smaller markup on the cost of the raw infrastructure. Most large organizations (AWS/GCE) have a model where they give some credit for the underlying infrastructure back to the team that servicized things. This is quite a bit different from a smaller startup that still needs to make some reasonable margin but has significant cost of goods of the infrastructure itself.

At the same time I fully agree with the notion that you should build and run a service, but if the marketing or even product perspective of such a thing is we installed a VM for you you're entirely missing the point. Having built an as-a-service product a few times over, there is a lot of engineering and product work that goes into it. Turn key backups, point in time recovery, high availability, performance monitoring are all not just installing a VM. And it's very different from building a core database engine. While there can be many benefits from collaborating on them, they are very different skill sets and the notion of focus shouldn't be underweighted.

To back you up on this, at the last place I worked we ran our own MySQL master and slaves for years, with moving to RDS always on the back burner. Finally completing that migration and shutting down our own servers was a big achievement. Never looked back, and were happy to be paying AWS to take care of the DBs for us.

I might be wrong by I think you missed maybe the most important keyword: backup. You can't fix a missing/corrupted backup, at this point it's too late. So you need to get it right. It's not like, say, configuring nginx. If you get nginx wrong you just fix it. If you need a backup and it's not there you can't fix it, it's (likely) game over.

So outsourcing the database is a very logical thing to do: if you can trust a third party to have a reliable backup/recovery story, that's one thing that can kill your business that you don't have to worry about.

>>> People pay us (Cloud SQL) and AWS (RDS) a surprising amount of money to run MySQL in a VM for them.

As a happy RDS user, I totally agree. Surely, I could run MySQL and the result would be mostly fine, after some mistakes and lessons learned. But all the things such as upgrading, etc still take time, add a bit of stress, one more thing to care about. Could that time and energy be spent on more valuable (from business point of view) activities? Yes.

I have regretted this decision.

This was a really interesting post. Thanks for writing it.

First with MySQL and then with MongoDB, a pattern is emerging. There's a popular open-source database. Its feature set is awesome and the ecosystem of software on top of it is good because lots of people are using it, but it's buggy and unreliable. So it's controversial. Since it's popular, it keeps being developed, and over time, it slowly gets more reliable.

To me this post is a reminder that, just because I can see clear flaws with a competing product, it doesn't mean those flaws are exploitable. Better to focus on what your own customers are demanding than on criticisms of your competitor.

The problem with MySQL early on was exactly its feature set. Fifteen years ago it was very far behind Postgres yet much more popular. I do not think it even had InnoDB/transactions at that point (or almost no one used it), definitely did not have user defined functions, procedures and many other features developers took for granted in commercial RDBMS.

Like MongoDB, it was popular mostly for being popular, which is a nice gig if you can get it.

Also it was fast on crappy hardware and easy to compile and setup. 80%. Better is worse. Unix.

That is not Unix. Unix is small, composable, correct and 80% of what you need (you write the rest). It doesn't mean 20% of quality was sacrificed.

The original "worse is better" example is precisely about Unix making a trade-off in which it gives up on "correctness"

Market timing, excitement (some of which later turns into hype), mindshare, and marketing make for a difficult combo to beat. The post-mortem covered addressed market timing and hinted at the rest, but is reluctant to call out MongoDB's marketing.

I can't help but wonder if the story had been different if the RethinkDB devs organized a bunch of codecamps and positioned their db as the 'default choice'. This is how Mongo gained a ton of mindshare, helped by other trends at the time, like the NoSQL wave, the Node.js boom, and the renaissance of client-side JS development.

> (...) Since it's popular, it keeps being developed, and over time, it slowly gets more reliable.

Or people simply don't care/are not willing to pay for alternatives. MongoDB looks as unreliable as it was on the first day, but somehow people don't seem to care. I hope it's because their use-cases can live with the unreliability, but in fear it's because "won't happen to me, just to others".

As a former startup founder, I totally empathize - it's always clearer with hindsight but it's important to honestly reflect so you can apply the lessons learned to the next turn of the ferris wheel.

> We set out to build a good database system, but users wanted a good way to do X.

If you replace "database system" with "[any product]," it encapsulates the reason why many startups fail. I was guilty of it too. I think it's a common pitfall for technical founders who tend to think in terms of solutions rather than problems.

If you have some free time, I would recommend the book What Customers Want by Anthony Ulwick, which offers a systematic approach to formulating a product that satisfies a market's underserved needs.

> I think it's a common pitfall for technical founders

There's a very closely related form that is common for non-technical founders which is "We're going to use technology to fix ____ industry"

A founder with experience in a particular industry may see how inefficient it is, and how much scope there is for improvement based on technological solutions, but business live-an-die by the question: "Are there enough people who will pay us to solve this problem for them?"

Superficially, it seems like "I can make your business run more efficiently" is a reasonable approximation for "I have something that you will pay money for", but it has a very similar value-gap to "I can provide you with a technically better database".

"More efficient" and "technically better" are both things that ought to be valuable to customers, but often aren't valuable enough to get them to hand over their money.

Nice write up! My outside personal perspective was that you needed to endure for longer. Things like Mongo rode the "Relational is a deadend, NoSQL to the rescue!" wave and gathered momentum before people started fully understanding the consequences of choosing Mongo. Now it seems there's a lot more caution being taken. Anecdotal accounts of people having success with things are taken with a grain of salt. People seem to be looking for more of a tidal wave of acceptance.

As an aside, lately it seems it's "OO is a deadend, Functional to the rescue!" ... so maybe you can leverage that wave instead... or deep learning... OverThinkDB maybe :)

The key to building developer tools is to build the ones that a developer needs but has no interest in creating. Backend for mobile, infrastructure for backend, etc.

Just don't create front end tools for front end developers, for example. Firebug had a donate button and we funneled all of it to volunteers in places where the currency was weak to make it at least seem material.

I don't think it's that simple. Which developer wants to build a reliable, realtime database?

Thanks for the post. One can feel your pain flowing through it.

I have a rather naive question: Why do you recommend "the Economist" as oppose to something like the HBR?

I've read the Economist for the last 20 years and the HBR for a few months before I dropped it.

The Economist offers insight, thoughtful analysis and writes about the world: literally but also politics, culture, and science. The obituary is surprisingly fascinating for instance. You may not always agree with its position, but you know that their position will be worth engaging with and thinking about.

No, I don't work for the Economist, I just appreciate thoughtful articles. Same goes for Private Eye, Foreign Affairs, New Yorker.

The best obituaries are in the Telegraph. I am still angry they have put them all behind a paywall :(

Aha interesting! Never read their obits. I find Evans-Pritchard a good read.

While I feel for you because failure hurts so much, congratulations on learning from your experience. I know this won't make you feel any better, but the next time you try things will be so much easier.

By the way the tone is fine given your experience.

Thanks for writing this, and writing it with candor.

What do you think of Spolsky's "Good software takes 10 years"?

https://www.joelonsoftware.com/2001/07/21/good-software-take...

It seems like you have a great ability to self-evaluate. Many of my friends and I, after reading your post, agree that we would be very willing to work in a team managed by people like you.

Sorry i am the one who leaked . @coffeemug we greatly appreciate your effort and rethinkDB is well architectured database in existance. We gonna keep using it and contribute to Rethinkdb .

Did you ever consider partnering with a larger vendor?

Figuring out the right GTM is tough, and the timing was weird, but GOOG and MSFT must have been pretty desperate for a NoSQL solution 2013-2014 to compete with DynamoDB. Firebase got scooped up in October 2014, but it wasn't until April 2015 when Azure announced DocumentDB.

Thanks for all your work.

I understand that you're waiting for a legal framework to accept donations as an organization, but there was an article recently about an individual GIMP developer being funded on patreon. Is this something you would consider? I'd be happy to contribute to someone who's actively working on RethinkDB (of course without any backer rewards or similar expectations), and perhaps others would as well.

Kudos on the post and for sharing. I really enjoyed reading the candor and hearing from your experiences. I heard amazing things about RethinkDB and admire your team for what you did.

I hope my finished writing is as good as your draft.

Thanks for pointing that out, just noticed the "/_drafts/why-rethinkdb-failed.md".

Thank you for the detailed analysis & post. I am myself embarking on a startup journey, albeit in the world of consulting & I wanted to let you know that your in depth writeup was extremely valuable & in many ways poignant to me. There were so many learnings in there and the way your bared it all, it feels it must have been excruciatingly hard to let go of your company (& co-workers) in the end. Thanks again & I wish you all the very best for your next venture - wiser & better.