RethinkDB: why we closed

Translation of the article was published with the permission of the author.

When we announced that RethinkDB is closing, I promised to write a critical analysis posthumously. I took some time to rethink the experience, and now I can clearly state it.

In the HN discussion thread, people described many reasons why RethinkDB failed, ranging from the inexplicable perversity of human nature, the cunning machinations of MongoDB marketers and the failure to build an experienced team ready to enter the market, ending with the lack of support for numeric types larger than 64-bit float. I summarized the comments in the list of reasons for failure, which were proposed.
')
Some of them have some truth, but they are more like symptoms than causes. For example, saying that we have not learned how to get financial gain is superficial. This statement does not cover the reasons why we did not succeed.

Looking back, I conclude that two things went wrong - we chose a tough market and optimized the product according to the wrong criteria of utility for the user. Probably, each of these errors reduced the value of RethinkDB by one or two orders of magnitude. Therefore, if we did one of these two things correctly, RethinkDB would have reached the size of MongoDB, and if we realized both omissions, we would eventually reach the size of Red Hat [1].

Hard market

Our thinking was approximately the following. New companies are not built on the basis of solutions from Oracle, so there is a niche in which there is an opportunity to build a company with a new infrastructure. The database market is huge. If we create a project that captures part of the market, we will come to the conclusion that we will become a very successful company.

Unfortunately, you enter the wrong market you think about - you are in the market where your users take you . And our users had a clear idea about us as a company engaged in open source tools, because that's what we are doing. Which turned out to be very sad for us, because the open source tools market is one of the worst markets anyone can be in. Thousands of people used RethinkDB, a part in the context of a business, but most wanted to pay for lifelong use for less than a cup of Starbucks coffee (that is, they did not want to pay anything at all).

This was not due to the fact that the product was so good that people did not have to pay for support, or because programmers did not control the budget or because of the collapse of capitalism. The answer is in the basics of microeconomics. Programmers love to develop development tools, often for free. And while there is a lot of demand, the offer is significantly ahead of it. The number of alternatives is inflated , and prices drop to zero.

To find out how this affects other companies, take a look at MongoDB (approximately $ 1.6 billion ~ 700 employees) and Docker (approximately $ 1 billion ~ 300 employees). Both companies are absolutely dominant in their markets. According to two generally accepted rules, growing private software companies are estimated at a rate of tenfold annual income, and the income per employee is about $ 200 thousand / year. Which means that MongoDB's annual income is approximately $ 140- $ 160 million, and Docker's annual income is about $ 60- $ 100 million.

This looks pretty good until we consider the prevailing B2B tech companies in markets that are not the markets of development tools. Companies such as SalesForce, Palantir, or Box (which face stiff competition). And suddenly MongoDB and Docker begin to look tiny.

Although it is an extremely successful company. If relatively established companies with partnerships, distribution infrastructure, and access to impressive accounts face growth problems, what does this mean for a startup that is in the germination stage?

For us, this meant a hard-to-manage sales funnel. If on a fertile B2B market, a startup needs to process one hundred leads to get ten opportunities, get one sale, then for a startup working on development tools, this number is multiplied by 10. You have access to many good prospects - many people download your product and interact with you, but you need to break through the freaking amount of leads to get close to the only sale.

This process has disastrous dominoes. The team is demoralized, it becomes difficult to attract investments and hire the best pros. In turn, this limits its own resources, so it becomes impossible to significantly invest in a product or distribution. Driving dynamics is a matter of life and death for startups, and the difficulties of spreading in the early stages almost always doom you to certain death.

Incorrect Utility Criteria

Well, the market is bad, but other companies involved in development tools still sell in large quantities. Why not RethinkDB?

Although we could not do anything with the dynamics of the market (except to do something else), product solutions were completely dependent on us. We wanted to build an elegant, reliable and beautiful product, so we optimized for the following metrics.

• Right. We gave very high guarantees and executed them strictly .
• The simplicity of the interface. We took on most of the implementation difficulties in order not to complicate the lives of developers.
• Uniformity. We did everything from the query language, client drivers, cluster configuration, documentation, to the advertising text on the cover as uniform as possible.

If this seems familiar, we took these qualities from work the worse it is the better . It turned out that correctness, simplicity of the interface, and consistency are incorrect criteria of utility for most users. Most users wanted these three options instead:

• Timeliness. They wanted the product to really function when they needed it, not three years later.
• Perceptible speed. People wanted RethinkDB to be fast under the loads that users actually gave, and not just the ones offered, which are close to “reality”. For example, they write quick scripts to measure how much they need to insert ten thousand documents without reading. MongoDB mastered these loads superbly while we fought in an already lost battle of training the market.
• Variants of use. We intended to make a good database system, but users wanted a good way to make X (for example, a good way to save JSON documents from hapi, a good way to save and analyze logs, a good way to create reports, etc.).

This does not mean that we did not try to run quickly, make RethinkDB fast, and build an ecosystem around it to do useful work easily. We did it. But correct, simple, and uniform software is time consuming. This caused our backlog from the market for three years.

By the time we felt that RethinkDB meets the set requirements, we were confident enough to recommend using it in production, almost everyone asked “how different is RethinkDB from MongoDB”? We worked hard to explain why correctness, simplicity, and consistency / compatibility are so important, but in the end these factors were not criteria of utility that mattered to most users.

To be honest, it hurts. Very painful. It was incomprehensible for us, why people chose a system that hardly does the thing it needs to do (store data), locks the kernel, scatters errors, functions as one node that stops working during segmentation, has a hardly working segmentation system, despite the fact that this is one of the key product chips does not guarantee correct operation and throws out a jumble of interfaces in which there is no consistency or unity of vision.

Every time MongoDB rolled out a release and people congratulated them on the improvements, I felt a surge of resentment. They said they would fix BKL, but in fact they lowered the level of detail from the database to the collection. They added more operations, but instead of a modular interface that would be combined with the system, they just screwed one-time commands. They could improve segmentation, but it was obvious that they did not want or could not give even elementary guarantees about the consistency of data.

But over time, I learned to appreciate the wisdom of the crowd. MongoDB turned ordinary developers into heroes when people needed it , not years later. This made data storage fast and allowed people to quickly deliver products. And over time, MongoDB has grown. One by one, they fixed architecture problems, and now this is a great product. He may not be as beautiful as we would like, but he does his job and does it well.

When it became clear in mid-2014 that we could not compete, we worked hard to be different from MongoDB. We found a very elegant way to add real-time notifications , hoping that this would allow developers to create a generation of applications that they could not do before. But this was not enough. Unexpectedly, we turned out to be competitors with Meteor and Firebase, companies that were committed to solving urgent problems, about which even a few years will not even be discussed. And again we were three years behind the market, again we found that we were not able to compete.

What about the clouds?

Several people suggested that we needed to make a cloud service. We actually had one such project in development, so this is an interesting topic that I would like to cover.

The obvious problem of a small company developing a cloud service is that it turns on a common failure mode - defocusing. It is difficult to develop, distribute and operate a multi-tenant cloud service. All this requires extraordinary experience and resources, so if you really enter this path, you may find that you manage two startups at once. But we were facing the threat of existence, and we quickly ran out of options, so we gave this idea a chance to shoot. Let's assume for a moment that we would be able to push through this idea.

Our reasoning was as follows. A database proposal could mean one of three things: managed hosting, a database as a service (DBaaS), or an extended platform as a service (PaaS). Let us return to the marketing analysis written on the knee, where we used the $ 200,000 / employee parameter in annual revenue, the same rule that we used earlier:

	Managed Hosting	DBaaS	PaaS
Company	Compose.io, mLab	FaunaDB	Parse, Firebase, Meteor
Employees	~ 30	~ 30	~ 30
Income	<$ 10M	<$ 10M	<$ 10M

These markets are small, even smaller than the database market itself. Maybe you should prefer one of them to the other?

Managed hosting is mainly about maintaining AWS databases for people. An alternative to using these services is to create a database on AWS yourself. It is a pain, but it is not so difficult. Therefore, there is a hard limit on how to evaluate managed hosting services. Considering that Compose.io and mLab offer MongoDB, which has an order of magnitude more clients than RethinkDB, we assumed that the managed hosting offer would not have much effect.

Database as a service is a more complex version of managed hosting, for example, the DBaaS service completely separates the management of nodes from the user. You just make requests and the system processes them. You just do not know anything about how many nodes run under the hood. This business is not very simple: partly because DBaaS companies have to compete with giants (such as DynamoDB and DocumentDB) and partly because customers are not inclined to fully transfer data management to a startup, as there are so many other options and alternatives ( Do you know someone who uses the services of DBaaS from a startup?) So, the proposal for DBaaS is left behind.

The last option was to develop an advanced platform as a service. We thought it was a promising direction, because we had a huge technical advantage in it. Firebase and Meteor had to build real-time application logic on top of MongoDB, which significantly limits the ability of real-time requests and performance to the right level. On the other hand, we could control the stack all the way, so we could offer significant advantages that were not available to Firebase and Meteor.

Therefore, we developed Horizon and started working on the Horizon Cloud, through which users would be able to deploy and scale RethinkDB / Horizon applications. The development of three large projects (RethinkDB, Horizon, and Horizon Cloud) with a very small team eventually overtook us, and we never managed to launch a cloud service before we ran out of money. However, respect the development team. They were very, very close.

Meta questions

There is another level of analysis of the main reasons that we can point out. Why did we choose a bad market and optimized the product for the wrong metrics?

When I was a kid, I wanted to make my own radio. I made a box of plywood, threw out some metal trash from the inside and connected the box to the power cord. I had books on electronics at home, but it seemed to me that I did not need them, I had an unshakable faith that I could do it myself. In the end, I built a working receiver, but it took me several years to finally understand that I needed to learn the basics of electronics.

Early RethinkDB was a bit like that. We had no intuition for products and markets, so we were simply driven by the idea of ​​building a company, not really understanding what we were doing. Moreover, we had an incredible optimistic attitude . Just as doctors know that gifts from pharmaceutical companies have an effect of addiction on other doctors, but they still believe that they are not affected by this effect, we also thought that we are not concerned with economic laws and the mathematical component of doing business. And, of course, in the end, math and crippled us.

Could we do something to avoid these mistakes? No more than I could have done in childhood with that radio. We did not realize that we were incompetent, and it took years for this incompetence to become conscious.

Several people said that we could improve our position if we built an experienced team ready to enter the market. This is 100% true, but the time for our personal development was not consistent with the needs of the company. Initially, we did not know that we needed expert knowledge and experience in entering the market, so we did not strive to include this in the necessary list of things to form a team. By the time we developed a type of thinking that matched well with reality, we were stranded on a tough market full of worthy competitors and a product that was three years behind. By that time, even the best market-adapted team in the world could not have saved us.

Goodbye Thoughts

Many people resent the developer tools market. Developers love making tools for developers, so they really want companies that make tools for developers to flourish.

I would not like to omit this market altogether - partly because I do not want to generalize from one experience, and partly because I don’t like to say “it is impossible to do” and partly because there are quite a few exceptions. GitHub, MongoDB, and Docker have created impressive companies. GitLab and Unity seem to be doing well too.

If you really intend to start a tool development company, proceed with caution. The market is full of good alternatives. User expectations are high and prices are low. Think carefully about the price you offer to the client. Remember - the desire that the world was so, you want, does not make it so.

In 2009, we talked about the original idea of ​​RethinkDB (we did not have software yet) to an audience of investors at the YCombinator demonstration day. We finished the report with slides in three key points. “If you can only remember three things about RethinkDB,” we said, “remember these.” It worked. People did not remember anything from the speech, but they did remember three points at the end.

I’ll finish with three key points to remember. If something is worth remembering from this article, then you should remember this:

• Choose a large market, but make for specific users.
• Learn to recognize the talents that you lack, then plow to get them into the team.
• Read The Economist without fail. It will make you better faster.

[1] Do not read these numbers too much. I gave a very rough estimate, but still had to give a general idea of ​​the cost of these errors.

[2] By the way, recognizing people who are competent in business without having good business intuition is as difficult as recognizing good engineers without having intuition in engineering.