RethinkDB: why we closed

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

When we announced that RethinkDB was shutting down, I promised to write a posthumous critique. 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 perversion 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 have summarized the comments on the list of reasons for failure that have been suggested.

Some of them have some truth, but they are more likely symptoms than causes. For example, the statement that we have not learned how to obtain financial gain is superficial. This statement does not illuminate 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 usefulness for the user. Each of these errors probably 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 had realized both of the omissions, we would eventually have reached the size of Red Hat [1].

Hard market

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

Unfortunately, you are not entering the market you are thinking about - you are in the market where your users take you . And our users had a clear view of us as an open source tool company, because that is what we are doing. Which turned out to be very sad for us, because the open source tool market is one of the worst marketsthat anyone might end up on. Thousands of people used RethinkDB, partly in the context of the business, but most wanted to pay less for lifetime use than for a mug of coffee from Starbucks (that is, they didn't want to pay anything at all).

This was not because 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 the basics of microeconomics. Programmers love to develop development tools, often for free. And while there is a great demand, the offer is far ahead of it. The number of alternatives goes up , and prices drop to zero.

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

This looks pretty good until we look at the prevailing B2B tech companies in markets that are n'tdevelopment tool markets. Companies like SalesForce, Palantir or Box (which face stiff competition). And all of a sudden, MongoDB and Docker begin to look tiny.

Although these are extremely successful companies. If relatively established companies with partnerships, distribution infrastructure, and access to impressive accounts face growth challenges, what does this mean for a startup that is in a sprouting stage?

For us, this meant a hard-to-reach sales funnel. If in a prosperous 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 plague of leads to get closer to the only sale.

This process has the disastrous consequences of dominoes. The team is demoralized, it becomes difficult to attract investment 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 start-ups, and distribution difficulties in the early stages almost always doom you to certain death.

Wrong Utility Criteria

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

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

• Right. We gave very high guarantees and strictly complied with them .
• The simplicity of the interface. We took on most of the implementation difficulties so as not to complicate the life of the 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 it seems familiar, we took these qualities from work; worse it is better . It turned out that the correctness, simplicity of the interface, and the sequence are the wrong criteria of usefulness 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.
• Tangible speed. People wanted RethinkDB to be fast under the loads that users actually gave, and not just under the offerings that are close to "reality." For example, they write quick scripts to measure how much it takes to insert ten thousand documents without reading. MongoDB mastered these loads superbly while we fought in an already lost market training battle.
• Use cases. 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 start quickly, make RethinkDB fast and build an ecosystem around it to make useful work easy. We did it. But correct, simple, and consistent software is time consuming. This caused our lag behind the market by three years.

By the time we felt that RethinkDB was satisfactory, 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 systemicity / compatibility are so important, but in the end, these factors were not usefulness criteria that mattered to most users.

To be honest, it hurts. Very painful. This was incomprehensible to us, why people chose a system that hardly does the thing that it should do (store data), blocks the kernel, is scattered by errors, functions as one node that stops working when segmenting, has a barely working segmentation system, despite The fact that this is one of the key features of the product does not guarantee correct operation and throws out a mishmash of interfaces in which there is no systematicity or unity of vision.

Every time MongoDB rolled out a release and people congratulated them on the improvements, I felt a surge of indignation. They said they would fix the 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 combined with the system, they simply screwed up one-time commands. They would have better segmentation, but it was obvious that they did not want or could not even give elementary guarantees about data consistency.

But over time, I learned to appreciate the wisdom of the crowd. MongoDB turned ordinary developers into heroes when people needed itnot years later. This made the data warehouse fast and enabled people to quickly deliver products. And over time, MongoDB has grown. One by one, they fixed architecture problems, and now it's a great product. He may not be as handsome 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 will allow developers to create a generation of applications that they could not do before. But that was not enough. Unexpectedly for ourselves, we turned out to be competitors with Meteor and Firebase, companies that devoted themselves to solving pressing problems, which will not even be discussed for several years. And again we were three years behind the market, again we found that we were not able to compete.

What about the cloud?

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 with a small company developing a cloud service is that it has a common fail mode - defocus. It’s 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 faced with the threat of existence, and our options for action were quickly running out, so we gave this idea a chance to shoot. Let’s suppose for the 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 advanced platform as a service (PaaS). Let us return to the marketing analysis written on the knee, where we used the parameter $ 200 thousand / employee in annual revenue, the same rule that we used earlier:

	Managed hosting	DBaaS	PaaS
Company	Compose.io, mLab	Faunadb	Parse, Firebase, Meteor
Staff	~ 30	~ 30	~ 30
Income	<$ 10M	<$ 10M	<$ 10M

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

Managed hosting basically consists of maintaining an AWS database for people. An alternative to using these services is to create your own AWS database. It is a pain, but it is not so difficult. Therefore, there is a severe restriction on how to evaluate managed hosting services. Given the fact that Compose.io and mLab offer MongoDB, which has an order of magnitude more clients than RethinkDB, we assumed that the offer of managed hosting would not have much effect.

A database as a service is a more complex version of managed hosting, for example, a DBaaS service completely separates host management from the user. You just make requests, and the system processes them. You just don’t 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 clients are not inclined to completely transfer data management to startups, while there are so many many other options and alternatives ( and you know someone who enjoys DBaaS services from startup?) So, the proposal for DBaaS left behind.

The final option was to develop an advanced platform as a service. We thought it was a promising area, 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 real-time query capabilities and performance at the right level. On the other hand, we could control the stack all the way, so we could offer significant benefits that were not available to Firebase and Meteor.

Therefore, we developed Horizonand started working on Horizon Cloud, with 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 still could not release a cloud service before we ran out of money. However, respect to the development team. They were very, very close.

Meta questions

There is another level of analysis of the root causes that we can point out. Why did we choose a bad market and optimize the product according to the wrong metrics?

When I was a kid, I wanted to make my own radio. I made a box of plywood, threw some metal debris 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 didn’t 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 incredibleoptimistic attitude . Just as doctors know that gifts from pharmaceutical companies have an addiction effect on other doctors, but they still believe that they are not affected by this effect, so we thought we had no economic laws and a mathematical component of doing business. And, of course, in the end, mathematics knocked us down.

Could we do something to avoid these mistakes? Not more than I could do as a child with that radio. We did not realize that we were incompetent, and it took years for this incompetence to become conscious.

Several people noted that we could improve our situation if we built an experienced team ready to enter the market. This is 100% true, but the time for our personal development did not agree 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 corresponded well with reality, we were aground in a tough market full of worthy competitors and a product that was three years behind. By then, even the best market-friendly team in the world could not save us.

Goodbye Thoughts

Many people are outraged about the market for developer tools. Developers like to make tools for developers, so they really want companies that make tools for developers to flourish.

I would not want to omit this market at all - partly because I do not want to generalize on the basis of one experience, and partly because I do not like to say “it is impossible to do” and partially 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 establish a tool development company, proceed with caution. The market is full of good alternatives. User expectations are high and prices low. Carefully consider the price you offer the customer. Remember - the desire that the world be like this, you want it, does not make it like that.

In 2009, we talked about the original RethinkDB idea (we didn't have software yet) of an investor audience at the YCombinator demo day. We finished the slide report with 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 remembered three points at the end.

I will end with three key points that are worth remembering. If something worth remembering from this article, then it’s worth remembering this:

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

[1] Do not read too many of these numbers. 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 good business intuition is just as difficult as recognizing good engineers without having intuition in engineering.