
RethinkDB Postmortem - v3ss0n
https://github.com/coffeemug/defstartup/blob/master/_drafts/why-rethinkdb-failed.md
======
bcantrill
Fascinating read, albeit a sad one: I love RethinkDB, and use it personally
every day in our particular production deployment.[1] But -- and to Slava's
point -- we didn't/don't/wouldn't pay for it, and in that regard, we were part
of the problem. That said, the constraint on that particular problem was that
it had to be open source, and if it couldn't have been RethinkDB, it would
have been some other open source database -- proprietary software is a non-
option for that use case (or indeed, for any of our use cases).

So I feel Slava's pain (and feel somewhat culpable as a user of RethinkDB),
but I don't _entirely_ agree with the analysis. Yes, infrastructure is a
brutal space because it has been so thoroughly disrupted by open source -- but
the dominance of AWS shows that open source can absolutely be monetized (just
that it must be monetized as a service). Indeed, right now, I would love to
deploy a RethinkDB-based service -- and if the company still existed, we (and
by "we" I mean "we Samsung", not "we Joyent"[2]) would potentially be in a
serious business conversation about what a supported, large-scale deployment
would look like. Actually, that's not _entirely_ true, and it leads to me to
one thing that Slava didn't mention. While it kills me to bring it up, it does
represent the single greatest impediment I have personally found to deep,
mainstream, enterprise adoption of RethinkDB: its use of the AGPL. Anyone who
has been part of a serious due diligence knows that the GPL alone is toxic to
much of the enterprise world -- and the GPL is a buttoned-down corporate
stooge compared to the virulent, ill-defined, never-tested AGPL. The AGPL is a
complete non-starter for any purpose, and while I appreciate why the AGPL was
selected by RethinkDB (and very much appreciate the explicit riders that
RethinkDB put on it to make clear what it did and didn't apply to), the
reality is that no one -- absolutely no one -- has built a business on AGPL
software and it seems vanishingly unlikely that anyone ever will.

I still use RethinkDB and still intend to -- and I still harbor hope
(crazily?) that whatever entity that owns the IP will see fit to relicense it
to something that is palatable to the kind of people who care about their
data. I actually believe that a business _can_ be built on the technology --
which, to Slava's points, I have found to be delightfully sound in both design
and implementation. And that RethinkDB is open source means -- for us, anyway
-- it will continue to live on, despite the unfortunate demise of its
corporate vessel (AGPL or no). That said, I would love to have a lot more
company -- here's hoping that we see RethinkDB relicensed and a thriving
business behind it!

[1] [https://github.com/joyent/manta-thoth](https://github.com/joyent/manta-
thoth)

[2] [https://www.joyent.com/blog/samsung-acquires-joyent-a-
ctos-p...](https://www.joyent.com/blog/samsung-acquires-joyent-a-ctos-
perspective)

~~~
rogerbinns
> ... the reality is that no one -- absolutely no one -- has built a business
> on AGPL software ...

MongoDB server is AGPL - client drivers are Apache. To be fair the business
side is based around larger scale deployment and management, and is
proprietary add-ons.

I'm kind of surprised that approach wasn't mentioned for Rethinkdb - a free
open core product, with paid extras dealing with pain points in larger
deployments.

~~~
williamstein
It is _possible_ to buy a different non-AGPL license to MongoDB --
[https://www.mongodb.com/community/licensing](https://www.mongodb.com/community/licensing).
With RethinkDB it seems completely impossible to do so. I begged and pleaded:
[http://sagemath.blogspot.com/2016/10/rethinkdb-must-
relicens...](http://sagemath.blogspot.com/2016/10/rethinkdb-must-relicense-
now-what-is.html). I just spent most of my time during the last two months
rewriting SageMathCloud to use PostgreSQL instead of RethinkDB, with the
catalyst for doing this being the AGPL licensing and some concrete enterprise
customers needing a completely non-GPL'd stack for SageMathCloud. Coming out
of this rewrite, and back to PostgreSQL (which I've used off and on for
decades), I'm very impressed by PostgreSQL today, and the LISTEN/NOTIFY
functionality is a solid building block on which to build something like
changefeeds (thanks to the many HN comments on previous stories about
RethinkDB for pointing this out!).

------
Perceptes
I really appreciate the deep introspection in this post. We can all learn a
lot from it. I'm one of the (possible minority) of HN users that doesn't care
about startups and business, so for me the takeaway was about how choosing
quality and correctness over speed works out in the real world. It seems that
you really can't take the idealist approach to quality that RethinkDB took.
The world just isn't willing to wait, and it's not willing to take the time to
understand a system and to see how clearly it distinguishes itself from the
alternatives. Our decisions are driven by speed. Our culture is "always be
shipping." But part of the result of this is that all our software is riddled
with bugs and usability issues. Even the most basic functionality of our
computers fail all the time, all the way down the stack. It's depressing that
a really solid, honest attempt to produce extremely high quality software like
RethinkDB can't survive in part because of these things.

~~~
andrewbarba
I was a huge advocate of RethinkDB, absolutely love what Slava and the team
were able to accomplish, but I am having a really hard time digesting that
"Correctness", "Simplicity of the interface" and "Consistency" were the issue
here. Example: Realm.

I can only imagine what the team at Realm is thinking after going through
comments and the post-mortem. Realm was an open-source mobile first database
for the past 3 years. It's free. Its the most correct, consistent, and simple
mobile database that is running on millions of devices[1] (Yup fine, kind of
my opinion but trust me mobile community will back this up). They ship FAST,
they ship real USECASES. They just recently entered the cloud space with their
Mobile Database Platform, and they are even experimenting with new things like
a version built for Node.js.

I'm honestly not trying to make a specific point, but asking more questions...
Is mobile different? Is it easier? Are mobile developers more willing to try
new technology? Are they more willing to pay for technology? (Realm is free,
haven't paid them a penny, so not sure about this one...)

My main point I guess is that it's not a terrible market, Realm made it work
with VERY similar ideals and goals. So what else is going on here?

[1] [https://realm.io/news/jp-simard-realm-core-database-
engine/](https://realm.io/news/jp-simard-realm-core-database-engine/)

~~~
ryanbrunner
I'm not familiar with Realm, but after a brief glance at their site:

Yes, mobile in this context is very different. Or rather, _local_ is very
different. Building a database that resides on a local device and is primarily
accessed by a single user is an entirely different class of problem than one
that is on a server. Usually most of the hard problems in building a database
system involves dealing with multiple people accessing or modifying data at
the same time. When you have a single user, that problem either disappears or
is massively reduced.

As you said, Realm does appear to have a server offering now, but from the
sounds of it, it hasn't really been proven yet, so I don't think it's as easy
as saying they've succeeded where Rethink failed.

~~~
andrewbarba
Absolutely, in no way am I saying their cloud offering is successful. What I
am saying is they have shown you can be successful with the very same ideals
and goals that the RethinkDB team had, with a very similar developer-minded
audience. The biggest factor here is obviously the platforms their database
runs on - Mobile (or local as you put it nicely) vs cloud.

------
vii
Slava (coffeemug) is very brave to introspect publicly and whenever I
interacted with him, behaved with greatest integrity and kindness.
Unfortunately, his hypothesis here that devtools are a tough market does not
ring true. Making a business is always tough, making one that does something
new is even tougher. There are many tools and database companies doing
extraordinarily well, from Atlassian to Cloudera to Docker to Elastic. The
difficulties that RethinkDB faced, as it pivoted from closed source MySQL DB
backend, to open source independent database with a very cool update
mechanism, were in my analysis much more mundane. Simply, RethinkDB was not
easy. Here is a flavor of their thinking, when they rejected a REST HTTP
interface: "The RethinkDB query language is so simple, expressive, and
pleasant, that trying to make it available over HTTP would be quite difficult
and a disservice to users."

Developers have a big advantage when making devtools in that they are their
own target market. They are, but only at the start of the project before they
become embroiled in it. Ironically this feeling of making it for oneself leads
to a mistaken urge to thrust complexity onto the target. As an infra engineer
myself, this is something I always try to keep in mind -- I worked on a
modelling language at a large company and I credit its success to its
absolutely straightforward and accessible syntax, lack of dependencies and
straightforward integration into workflows. The temptation is always to make
sure users are aware of the choices, force them out of bad habits and make
them consider the tradeoffs (this Strange Loop talk from Peter Alvaro
addresses the social treatment of users
[https://www.youtube.com/watch?v=R2Aa4PivG0g](https://www.youtube.com/watch?v=R2Aa4PivG0g)
). For RethinkDB, it was wrong to try to force people to learn a new language
to use a DB, when there are just tons of interfaces already, and the new
language has incremental benefits over say SQL.

However elegant the design of software, the deployment that is the largest or
most demanding for it will always find problems. There's no point seriously
trying to claim great reliability or quality for a nascent project. It's
unbelievable. Instead you need to focus on getting it used in some friendly
project that is willing to pay the cost of these teething problems for some
particular feature. Once battle tested, reasonable tech leads can choose to
use it, comfortable that they won't be the biggest deployment (e.g. git
bootstrapped by its use in the Linux kernel). Alternatively, and less
scrupulously, you can try to bootstrap by providing a very convenient
experience at the start of a simple project for junior engineers - there are
many NoSQL DBs that promise the world and are incredibly easy to set up (see
the [https://aphyr.com/tags/jepsen](https://aphyr.com/tags/jepsen) Jepsen blog
for many sad examples, RethinkDB proudly did well in this test).

RethinkDB refused to make the market fit compromises necessary. Market fit is
about timing. Don't read the Economist. Ship early and keep your users on
board through whatever engineering compromise necessary.

~~~
williamstein
I spent 1.5 years writing a ton of code using RethinkDB, and the last two
months rewriting all the code (and more) using PostgreSQL. __You are
completely right __, e.g., "For RethinkDB, it was wrong to try to force people
to learn a new language to use a DB, when there are just tons of interfaces
already, and the new language has incremental benefits over say SQL." rings
very true. SQL is incredibly expressive and the tooling around it is very
mature.

~~~
tshannon
So I disagree with this. One of the things I loved about RethinkDB was the
fact that it did away with SQL. The problem with SQL (in high transaction
applications anyway), is that performance isn't necessarily reproducible, or
determinable from the query. You are at the mercy of how the query optimizer
decided fetch your data. The more complicated your query, the less you can can
out reproducible performance.

With RQL you could very clearly determine how rethinkdb was fetching your
data, and you knew it was going to get your data in the same way every time
the query ran.

------
coffeemug
Hey all, author here.

FYI, the post is still in its unpublished state. It's basically right, but
I've been meaning to edit it for tone and rewrite the market failure section
for clarity. Didn't get the chance to do that before it made it on HN, so keep
in mind that you're reading a (late) draft.

~~~
boulos
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.

~~~
craigkerstiens
> 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.

------
notacoward
Here's the part that resonated with me.

> we fought the losing battle of educating the market.

I've been at ten startups. At least half of them chose that battle, and that
would be the less successful half. Sales cycles are fragile things. Anything
that slows them down can be fatal. Clearly you need to explain how your
offering is unique and special, but if you have to pause to explain basic
concepts before they get it then you've probably lost their attention and
their business.

The VP of marketing at one of my previous companies was generally an idiot and
one of the chief drivers of that company's failure, but he introduced me to
the concept of market vs. technical risk. A product can be easy to market but
a challenge to build, or it can be the other way around. You can build a
strategy around either. If it's hard in both ways, you're in trouble. Frankly,
it sounds a bit like that's the trap RethinkDB fell into. They were doing
things that were technically hard _and_ hard to explain to users. That's how
you get three years behind.

It's a sorry situation, but kudos to the RethinkDB folks for trying to do the
right thing, mostly succeeding from an engineering perspective, and writing
honestly about how that played out in a market of people who aren't equipped
to appreciate it.

~~~
SadWebDeveloper
> if you have to pause to explain basic concepts before they get it then
> you've probably lost their attention and their business.

And this point of failure for many startups was beautiful represented/mocked
in the silicon valley series of hbo:
[https://www.youtube.com/watch?v=Lrv8i2X3gnI](https://www.youtube.com/watch?v=Lrv8i2X3gnI)

------
v3ss0n
Hello HN , sorry for the early leak. I posted as I've discovered on github
after looking around rethinkdb progress.

RethinkDB as a product is not dead.The community and one of ex RethinkDB
senior developer are still maintaining it. Since it is fully Opensourced , we
are welcoming contributors , lets make RethinkDB great , together!

[https://github.com/rethinkdb/rethinkdb](https://github.com/rethinkdb/rethinkdb)

Here are current rehtinkdb plans :
[https://docs.google.com/document/d/1f8qODp7voKIqwioQ3si69q3-...](https://docs.google.com/document/d/1f8qODp7voKIqwioQ3si69q3-ruc7h3ncfH0KoHYv_4k/)

Most of ex RethinkDB developers are going to keep contributing rethinkdb,
after things got settled down a bit.

[https://docs.google.com/document/d/1c27S3Ij2WLB_JiUmpIGkbwJO...](https://docs.google.com/document/d/1c27S3Ij2WLB_JiUmpIGkbwJOgVL8T7nW0sPz7OJZjro)

Please try out rethinkdb , and if there any questions we are activly answering
at :
[https://rethinkdb.slack.com/messages/general/](https://rethinkdb.slack.com/messages/general/)

Please join [https://rethinkdb.slack.com/messages/open-
rethinkdb](https://rethinkdb.slack.com/messages/open-rethinkdb) for
OpenRethinkDB updates.

Thank you very much , rethinkdb is an excellent Database. I see a lot of New
users at RethinkDB slack. Before RethinkDB slack was quite empty but now it
have lot more active user after RethinkDB Shutdown.

@coffeemug , those who've tried rethinkdb are staying with rethinkdb. The
product is not a failure and the actual users values the standards you have
set!

Many of us are going to stay with RethinkDB .

~~~
neoeldex
Haven't tried recently, but the only way to install RethinkDB on my machine
(ubuntu) was running the docker image. Is it currently fixed again?

~~~
v3ss0n
it can be easily installed on Ubuntu:

source /etc/lsb-release && echo "deb
[http://download.rethinkdb.com/apt](http://download.rethinkdb.com/apt)
$DISTRIB_CODENAME main" | sudo tee /etc/apt/sources.list.d/rethinkdb.list wget
-qO-
[https://download.rethinkdb.com/apt/pubkey.gpg](https://download.rethinkdb.com/apt/pubkey.gpg)
| sudo apt-key add - sudo apt-get update sudo apt-get install rethinkdb

------
joshberkus
Coffeemug: there's one other thing you missed in the postmortem. The early
marketing (1st year) for RethinkDB was all about optimizing for SSD storage.
Since this was largely nonsense, database consultants like me (who were in a
position to push technically correct solutions) read about it, and dismissed
RethinkDB from our thoughts forever. I keep up pretty well with the OSS DB
field, and didn't realize what you were really trying to build until five
years later. With the number of NoSQL and NewSQL DBs entering the market in
2007-2010, I simply didn't have time to re-evaluate any of them.

So that's an other "take-home" from the post-mortem: be careful about your
"first impression" on the market, because it can be _really_ hard to change.

~~~
jhchen
Why is optimizing for SSDs nonsense? Empirically this seems correct since
RethinkDB themselves pivoted away from this but curious about the technical
explanation.

~~~
Plugawy
coffeemug explained it himself in a podcast where he was interviewed about
Rethinkdb (I don't remember the name of the podcast). Basically it boiled down
to the fact that all existing databases (at that time) could be tuned with
very little effort to take advantage of SSDs so that differentiating factor
flew through the window

~~~
joshberkus
Exactly.

------
StavrosK
I don't know, my personal opinion was that RethinkDB had its head on straight,
MongoDB is garbage and still neither is so much better than PostgreSQL that I
will switch away from it.

Postgres is the default datastore (because schemas are awesome) for me, and I
haven't had a use case yet where I needed something that Postgres wouldn't do.
Maybe if you have a very specific need, you'd reach for another datastore
(come to think of it, I have successfully used Cassandra for multi-DC
deployments of a distributed read-only store), but that's not the norm for me.

~~~
slake
I agree Postgres is pretty awesome, but I think the one thing it has going
against it is a good GUI client. MySQL has way too many good options wherease
Postgres is stuck on this front.

~~~
fooey
I've tried really hard to like Postgres, but coming from SQL Server land, the
tooling is mind blowingly atrocious. Every few months I go on a google spree
trying to find the magic tool to make it less painful, but everything is
either just as awful as pgadmin or costs way too much.

~~~
ianamartin
Microsoft gets a lot of shit for various and mostly good reasons. But their
tooling is seriously top notch. I would murder kittens to get tools like SSMS
for postgres.

Hell Python Tools for Visual Studio almost makes me want to do python dev work
on a PC.

------
antirez
This was an excellent reading. No surprise given the author. I think there is
a missing element about this in the post:

> Correctness. We made very strict guarantees, and fulfilled them religiously.

It is true that the user base did not recognize this as important as the
RethinkDB team, also because there is part of the development community which
is very biased towards this aspect of correctness, at the point that you
literally never experienced a problem for years with a system, but then a blog
post is released where the system is shown to be not correct under certain
assumptions, and you run away. So part of the tech community started to be
very biased about the importance of correctness. But 99% of the developers
actually running things were not.

Correctness is indeed important, and most developers have indeed less interest
that they should have in formal matters that have practical effects. However,
I don't think this point can be simply reduced to developers ignorance, that
make them just wanting the DB to be fast in micro benchmarks. Another problem
is use cases: despite what top 1% people say, many folks have use cases where
to be absolutely correct all the time is not as important as raw speed, so the
reason they often don't care is that they often _can_ actually avoid caring at
all about correctness, as long as things kinda work, while they absolutely
need to care about raw speed in order to take things up with a small amount of
hardware.

~~~
raverbashing
I'd say that for more than 90% of potential RethinkDB users there's no need
for guaranteed correctness (several exception are in FinTech or similar areas)

But even in those cases, the operation can be retried or the operation could
take longer

If you're "Social startup of the year" it doesn't matter if one post appear to
some followers 100ms later than they should be.

~~~
bad_user
In my opinion, you got it backwards. Fewer than 0.1% of software engineers are
working on the " _social startup of the year_ ", whereas the other 99.9% of
developers are working on software where consistency and correctness matter
more than availability.

And for most of those developers, atomicity guarantees (the A from ACID) are
very important, because without transactions if that one operation fails,
before it can be repeated as you say, the system also has to rewind the
previous operations that succeeded in order to leave the data in a consistent
state and implementing this rewind by yourself is extremely challenging (take
a look at the Command pattern sometime for a possible strategy).

Or in other words, most developers need atomic guarantees / transactions as
well and if the DB doesn't support transactions with the needed granularity
for your app, it's easier to change the DB than implementing it yourself,
which is why RDBMSs are still more popular than NoSQL systems, because they
are more general purpose and made the right compromises for a majority of use-
cases.

~~~
raverbashing
Thanks for your comment

I don't disagree consistency and correctness are important, but it's the same
with uptime, where to have it an order of magnitude 'more confidence' you have
to spend more time/resources (because even if your DB did everything right,
your hard drive could have had a glitch, etc)

There are ways of working around the lack of atomicity, for the cases where
you really need that guarantee (I really wouldn't try "writing my own" generic
transaction manager, but you can try relying on the atomic operations and
limiting changes to small steps - and if you wrote information that is
irrelevant now because the operation didn't finish _that 's fine_ \- you can
gc it later)

Now if the operations you need to do are very complex then it is probably
better to keep using RDBMSs

------
sontek

        > People wanted RethinkDB to be fast on workloads they actually tried, rather than "real world" workloads we suggested.
    
        > For example, they'd write quick scripts to measure how long it takes to insert ten thousand documents without ever reading them back.
    
        > MongoDB mastered these workloads brilliantly, while we fought the losing battle of educating the market.
    

I was one of the people who did this and I'd like to provide you another take
away:

Don't tell people what "real world" workloads are. They know better than you
do. When I presented my performance testing scripts to you guys it was a
replication of _our_ real world workload. Trying to explain to someone that
their workload isn't "real world" hurts the confidence in the system. Its
better to either say that isn't a workload you are optimized for or that you
are working on it.

That being said, I'm now building a start-up and using RethinkDB because it is
the best system out there! My performance requirements for a start-up are
significantly different than the billion dollar survey company I used to work
for ;) But I'd also like to commend you on the performance you've achieved
with RethinkDB in general, it has come a long way and any company would be
happy to hit the scale that RethinkDB has issues with!

~~~
v3ss0n
Very nice to see people keep using and using RethinkDB for new products. We
have one in productions. are also starting 2 more new products that is built
upon rethink db. A Chatroom and an Realtime Geolocation /Map based app. Please
join rethinkdb slack ! we are building back community,

------
karlunho
There is bigger market forces that isn't being considered here - namely that
the entire database as a service margins have been nearly driving down to zero
by AWS. Why do you think firebase had to sellout to Google ? Why did Parse
shut down ? Simply because the big cloud vendors figured out that providing
paas services at nearly the cost of the infrastructure will win them even more
compute workloads which is the real money maker (especially if your are
reducing your computer pricing slower than Moore's law)

~~~
dboreham
Right on the money, so to speak.

He says that the market was terrible because open source developer tools
suffer from oversupply. I don't think that's what happened. Rather they chose
to make a product for which the next best alternative (e.g. Mongo or Cassandra
or MySQL or Postgresql) had almost zero cost. It doesn't matter how
oversupplied the market is if someone is willing to give away a viable product
for free. Perhaps "oversupply" is another way to say "someone was willing to
sell at zero cost", I'm not sure.

Unless you can find a set of customers who see significant value in your
product vs. the alternative zero-cost product, you're never going to make
money.

------
atnnn
Some of us are keeping the RethinkDB database and community alive. The code is
open source, and development continues slowly. The next release is almost
ready. It'll have new features and performance improvements.

~~~
v3ss0n
Thank you very much @atnnn for continued keeping RethinkDB alive.

------
jwr
I am using RethinkDB in PartsBox
([https://partsbox.io/](https://partsbox.io/)). I initially picked it because
I wanted a JSON document database that has a correctly implemented distributed
story. But later on it turned out that the realtime-push (changefeeds)
functionality is actually fundamental for me. I used it to build an app where
every open sessions gets instant updates.

Right now I don't know what other database I could use, because I found no
other solution that supports this kind of functionality, _especially_ in a
distributed setting.

I agree with most of your analysis and I think that the most important part is
about "worse is better": many of your potential customers won't understand or
won't care about correctness or consistency.

That said, I really like RethinkDB (oh, it does have its warts, but overall
it's great), I'm very thankful for it, and I hope it will continue as an open-
source project.

~~~
jinjin2
It is a very different model, but have you tried Realm?

It is more of an object model that a straight up JSON store, but it has some
of the best notification features I have tried. You can observe both object
and query results in realtime, and since the dataset is replicated to you it
has zero-latency local access.

They used to only support mobile, but now they also have a node.js version for
server side use.

In my opinion Realms observability is light years ahead of all the other
offerings out there.

~~~
jwr
Yes, it looks really good — but it's a different kind of database (I think).
From a quick glance, it's an embedded object database used mostly client-side,
while what I need is a distributed server-side database.

------
yummyfajitas
I do find it truly sad how anti-intellectualism is pervading our industry and
causing good products to die. Nowadays, a significant number of the hottest
new technologies offer literally nothing of value beyond "low learning curve".
It's my current belief that tech culture has lost nearly everything that once
made us great.

Think about some examples.

MongoDB is nothing but the object databases of the 80's, rebranded. It's main
selling point is "you don't need to learn SQL". Object databases failed and
people at the time were willing to learn something new (SQL). Nowadays, who
will do that?

Go's entire selling point is "faster than python, no need to learn anything
new". In terms of language features it's again living in the 80's - Java got
generics in 2004 and Java was way behind the times. In terms of speed it's
worse than Java and Rust, maybe comparable to Haskell.

And NodeJS is nothing but "write server code, no need to learn a new
language". Isomorphism simply didn't work. People think Node is fast because
it can do async, but Java has been able to do _threaded_ async for 15 years.

I wonder how much the industry could advance if we could simply persuade every
developer to learn Java Postgres.

~~~
lelandbatey
I'm going to fundamentally disagree with at least the target of Go. Go
introduced a series of concurrency primitives with syntax that's made writing
and reasoning about concurrent code a joy, something that's not the case in
Java/C++/C/Python (maybe up till the late 3.X in the case of Python), and it
did that with a language paradigm (interface driven) that's _vastly_ different
from Python's mixture of OOP and duck-typing.

And sorry, but _" I wonder how much the industry could advance if we could
simply persuade every developer to learn Java Postgres."_?

Plenty of other people would say "I wonder how far along the industry would be
if you people would actually learn how to manage your memory and write C".

Plenty of other people would say "I wonder how far the industry would have
progressed if we let go of the harmful and outdated concept of imperative
programming and embraced functional paradigms."

... and on it goes.

\-----------------

Additionally, you say _" I do find it truly sad how anti-intellectualism is
pervading our industry"_ only to end your post with _" why can't we abandon
all our experimenting and learning and just stick to good old Java which
obviously would solve all our problems"_, which is itself _MASSIVELY_ anti-
intellectual.

~~~
yummyfajitas
Go didn't "introduce" CSP or actor like primitives. Scala had actors in 2006,
I think Clojure has for a similar amount of time as well. There have been
libraries for it in Java and C++ also since the early 2000's and probably
earlier.

 _Plenty of other people would say "I wonder how far along the industry would
be if you people would actually learn how to manage your memory and write C"._

I don't see the industry gravitating towards bad re-implementations of C with
less functionality and a flatter learning curve. The only "replacement" for C
that I'm aware of is Rust, and Rust is most definitely not anti-intellectual
in the same way I criticize Go.

Rust actually requires the developer to learn new concepts (borrow checker)
which are not found in C, Python, Java, etc.

 _" why can't we abandon all our experimenting and learning and just stick to
good old Java which obviously would solve all our problems", which is itself
MASSIVELY anti-intellectual._

I didn't say to end experiments. I said everyone should actually learn some
fundamentals before jumping on low-learning curve bandwagons which offer
nothing new.

~~~
geodel
> Rust actually requires the developer to learn new concepts (borrow checker)

Well they do not want GC for their language hence borrow checker while Go
already has an excellent GC.

As opposed to learning new things we need useful new things which couldn't be
done before fancy new language.

~~~
yummyfajitas
So what can you do in Go that you couldn't do (without a lot more difficulty)
in Java or Haskell?

------
hoodoof
Interesting perspective.

The article talks alot about big companies that make lots of money but as a
user of databases I always saw the competition to ReThink DB being Postgres,
MySQL and to a lesser extent ArangoDB and MongoDB.

The core problem for Rethink being that, well, I can get as much database as I
want for free. I explored many/most of the new/nosql databases and in the end
always found that Postgres was the best solution - you just shouldn't bet
against Postgres it seems.

I really liked RethinkDB and thought it was well implemented but it just
wasn't _needed_.

I do wonder if ArangoDB is going to go the same way.

~~~
lobster_johnson
Exactly this. RethinkDB's value proposition wasn't really that attractive
compared to Postgres.

Replication and a nice UI, sure, those are nice. But Postgres has _fantastic_
single-host performance, and Rethink is not yet in a position to compete
there, except in some horizontally scaled use cases. Rethink doesn't even have
transactions, making it potentially useless for some things that require
strict atomicity over a complicated data model. In general, Postgres has such
a richness of features that it's hard to compete with it; PostGIS alone is a
"killer app" if you do any kind of GIS stuff.

For me, there weren't any such "killer app" features. The change streaming is
nice, but it's not difficult to do that with Postgres either. That's it
really: Every solution offered by Rethink could be countered with "that's
nice, but trivial with Postgres".

The one exception being horizontal replication. I have yet to launch a project
where Postgres couldn't scale out well enough, and I suspect that if I got to
that point, I would reach for bigger/different guns such as Cassandra. For our
apps we typically use Elasticsearch in front as a kind of read-only mirror of
Postgres; the latter being the slow, serializable path, and the former the
fast, slightly-out-of-sync path. Users don't know the difference.

~~~
zigzigzag
Firstly, to the OP, that is an excellent post-mortem. Introspective, goes
deep, generally confidence inspiring even though a part of it is literally "we
were incompetent and didn't know it", well, lessons learned.

I'd like to add some colour, although I've never used RethinkDB so take it all
with a large pile of salt.

lobster_johnson says:

 _> Rethink doesn't even have transactions_

The post-mortem dwells heavily on how RethinkDB focused on correctness and was
beaten by MongoDB which is, to put it mildly, not concerned about correctness.

But Rethink is a JSON DB that apparently doesn't have transactions and which
on its web page says "Query JSON documents with Python, Ruby, Node.js or
dozens of other languages".

Here are three technologies I do not strongly associate with correctness:

* JSON

* Schemaless databases

* Scripting languages

Rethink's own FAQ says "RethinkDB is not a good choice if you need full ACID
support or strong schema enforcement".

So in the database market there are of course lots of users who do strongly
value correctness, but they tend to use databases and technologies that are
statically typed (Java/C#) and database engines that have are ACID and provide
schemas.

Very few of them want a database that doesn't provide ACID, doesn't provide
schema enforcement and which appears to either not support standard industrial
languages at all, or is at least distinctly uninterested in them.

In other words Rethink targeted the hipster startup market of companies
building social networks, ride-hailing apps and other things where correctness
is not important and low-correctness tech dominates, but tried to sell a
product that was oriented around correctness. This seems like a market/product
mismatch.

~~~
lobster_johnson
That's a good point. Competing with MongoDB is difficult because "correctness"
alone is not a selling point. It's the "worse is better" phenomenon as a
marketing challenge.

That said, I don't think lack of correctness itself is a design goal. I think
it's accidental, or at least an intermediate state before we have something
better.

Case in point: I'm currently working on an open-source (it will be released
soon) data store that uses JSON to express "documents" of data, but also has
schemas, joins _and_ transactions. It uses PostgreSQL internally, but
completely hides the underlying storage. The developers who are currently
using it for actual work are pleasantly surprised about how nice it is to work
with: You get to work with rich, structured data in its natural shape without
needing some kind of ORM to mediate between an app's data model and the
database's, and at the same time it's very strictly validated without being
pushy (it has gradual typing: you can start out schemaless and then tighten
the schema). When we designed it, we wanted to build something that reflected
how people actually use a database, and I think we're achieving that. (I'm
looking forward to make it public and share it on HN.)

So it's certainly possible to have the best of both worlds. It's just that the
direction that the world moved in with "NoSQL" temporarily moved us off course
for a little while. It started out as a natural reaction to scaling issues,
and in that sense I think it might have been a necessary step while people
figured out what they were doing. We're seeing the same evolution in the ways
of people's thinking with regard to dynamically/statically typed languages,
too.

------
kriro
As someone who has worked at a bootstrapped B2B FLOSS company in the
ERP/database domain I think taking/relying on venture capital is a dangerous
model in that domain. I feel like the best options are:

1) Don't build a company around your FLOSS project, accept it'll be free in
all senses forever

2) Start with a customer that will finance you and build slowly (focus on
profit not revenue)

That's obviously not very helpful as finding that one customer is the really
hard part so it's usually a hybrid of expecting what you build to be free
forever and then finding that one customer. Quote/Charge a lot. Nope more than
that. Now double the price and you're roughly there.

On the plus side you'll get very enthusiastic developers that tend to be
intrinsically motivated which is a huge plus once you can build that company.
I'd argue that this is one of the key competitive advantages of a "FLOSS
company"

When it comes to new customers...Always be aware that you're not selling your
cool tech but rather selling the solution to a specific problem (basically
you're selling pain-easing medicine). I feel like it is beneficial to
visualize a somewhat mean guy at the other end of the table who is only
thinking this one line over and over "enough with the nerd speak, how does it
help me and does it roughly cost what I expect it to cost". Yes we like to
imagine that we can impress people with nifty tech details and shudder that
the competition might be "that horrible Oracle database every developer
hates". Hand in hand with this...charge a lot. The price serves as a signal.
Just assume that evil guy you're talking to only cares about getting back to
that golf course and won't even look at the number that closely as long as
it's fitting his expectation. Yes that means charging too little can kill your
deal.

------
dkarapetyan
Out of all the databases I tried throughout the years RethinkDB was the best.
His bit about "worse is better" nails it I think. It was an elegant product
targeted at the wrong group of people. ReQL alone was a masterful piece of
design and it was great fun composing queries in Ruby instead of some weird
JSON frankenstein DSL. At one point I was pushing 500k events per hour through
a single node on an c4.xlarge instance with plenty of room to grow. I'm sure
other databases would have handled the load just fine as well but I didn't
really want to find out because RethinkDB was so much fun to play with. I was
very sad when I heard they were shutting down.

~~~
v3ss0n
The product still lives and development is continuing slowly. There is almost
daily commits there. We need more contributors! @atnnn ( ex rethinkdb
developer) and community is working on it.
[https://rethinkdb.slack.com/messages/open-
rethinkdb](https://rethinkdb.slack.com/messages/open-rethinkdb)

------
lvca
Nice reading and Kudos to the entire RethinkDB team for what they have done,
especially the evangelization of the Reactive Model in the database. This
inspired other vendors like OrientDB to do the same.

Running a company where a large part of the users is developers is very hard.
The secret sauce is providing a good product and create a business where some
of the users would pay to have something more, like support and/or an
Enterprise edition.

The truth is, AFAIK, no NoSQL company backed by VC is still profitable today.
Not even MongoDB that has got more than $300M and is able to collect just
$60M/year by spending much more to be up & running.

Disclaimer: I'm the author of OrientDB.

~~~
tom_mellior
> The secret sauce is providing a good product and create a business where
> some of the users would pay to have something more, like support and/or an
> Enterprise edition.

I was wondering about this, as it's not explicit in the article: What _is_ the
business model that makes money for Docker and MongoDB? From MongoDB's website
I gather they have some "Enterprise" things, but they want me to give them my
personal data just to access a "datasheet" describing this. Docker's
"Enterprise" offering seems to be a mix of support and hosting.

So is that it? Support, hosting, and donations from Big Business?

The article also says: "Thousands of people used RethinkDB, often in business
contexts, but most were willing to pay less for the lifetime of usage than the
price of a single Starbucks coffee", but I don't understand what those users
would have payed _for_. What was the product being sold? All I can gather from
the article is some cloudy hosty database-as-a-service thing that might have
made money but never shipped.

~~~
niftich
Support. Notwithstanding more widely accepted benefits of support like a
direct line to the product's experts and in some cases, developers, big orgs
are political tinderboxes and you're always one bad downtime away from an
internal catastrophe, let alone an outage that affects customers. It's
therefore often politically _wise_ for decision-makers to purchase support
even in cases where the risk analysis might show that internal talent resolve
or work around most issues.

This is a variation of the "no one ever got fired for IBM" trope, and is in
fact a big moneymaker for the likes of IBM, Oracle, Microsoft, and the like,
even in situations where the standard notions of vendor lock-in may not even
apply.

------
haddr
I don't get this: "Read The Economist religiously. It will make you better
faster". Anybody could explain?

~~~
hackcrafter
It's a bookend to the recurring point that building a business requires a good
understanding of markets and how companies fight for their place in them.

The Economist covers a lot of macro-economic news and frames the world in
terms of market forces.

I think Slava is saying the type of biz-savy "personal development" he
experienced (belatedly) could have been accelerated by more of this
perspective.

------
mstipetic
I was working in a company where we built a new backend system and had the
opportunity to chose the technologies we'd use. I was constantly looking at
rethinkdb waiting for them to tell me "Yes, you can use this now," however
their blog posts and announcements constantly had the underlying message of
being in some kind of alpha or beta state.

Admittedly, that was a few years back, so that could have been true then, but
the feeling stuck with me and I just stopped taking it seriously.

The problem is that they got a lot of attention early on and expectations were
huge and instead of building some hype around it, they were actually too
honest. In hindsight I, as an engineer, would have probably done the same, so
I think there are some valuable lessons there about marketing and human
psychology. At least that part the people at MongoDB did brilliantly.

------
hkailahi
I'm surprised there are no comments here, this is the best thing I've seen on
HN in a while.

~~~
sytse
I agree, let me take a stab at starting the conversation.

First of all, huge respect to Slava for this writeup. Having your startup fail
is hard and it is not the time you want to blog about it. RethinkDB going
broke was a sad thing to see for me, I can't imagine how it felt for him.

I think the analysis of the two root causes (hard market, focus on the wrong
metrics) is accurate. It is very sad to see that in the end correctness
doesn't win the day, not even for databases.

Since I run a startup too I can't help but apply his criteria to GitLab.

Good metrics to focus on:

1\. Timely arrival => we try to ship great features every month on the 22nd,
something that both our users
[https://twitter.com/PragTob/statuses/767777202045915136](https://twitter.com/PragTob/statuses/767777202045915136)
and the parody account likely run by our competitors employees agree on
[https://twitter.com/gitlabceohere/status/768440048802947073](https://twitter.com/gitlabceohere/status/768440048802947073)

2\. Palpable speed => we're doing OK on self hosted, really bad on GitLab.com
(fixes are in [https://gitlab.com/gitlab-
com/infrastructure/issues/947](https://gitlab.com/gitlab-
com/infrastructure/issues/947) ). If you look beyond latency but to workflow
we're doing great in integrating various parts of the process
[https://about.gitlab.com/2016/11/14/idea-to-
production/](https://about.gitlab.com/2016/11/14/idea-to-production/)

3\. A use case => we're making GitLab an integrated tool with a broad scope
[https://about.gitlab.com/direction/#scope](https://about.gitlab.com/direction/#scope)
A good way to develop software from idea to production.

I hope the above list doesn't come across as pretentious. I welcome pushback
and the opportunity to talk more about the OP.

I think the OP premise that it is hard to make money in the cloud is accurate.
We're spending hundreds of thousands of dollars to make GitLab.com run and
revenue takes a long time to grow. Selling on-premises software products has
higher margins than a service.

BTW I appreciate the shoutout to GitLab as one of the five exceptions that are
doing well in the open source developer market.

~~~
FooBarWidget
Thanks for your insights on this postmortem Sytse. Love how you are leading
Gitlab.

------
spullara
I'm the Series A investor in FoundationDB, met with RethinkDB really early on,
and really appreciate your post.

------
sikan
Why not position yourself as the better mongodb? You explained pretty well in
the post mortem (and to yourself in 2014) how much better rethinkdb is to
mongo. All you had to do was aggressively market yourself as the better option
by directly comparing yourself to it.

I remember when iPhone first launched, the first 30 min was spent just
trashing then-current smartphones - the blackberrys.

~~~
gabesullice
I think he did mention this indirectly. Mongo performs better than Rethink on
metrics that have nothing to do with what you truly want from a DB. He
mentioned developers that would just whip up a script to throw thousands of
writes at the database but never reads. Use cases that they would never see in
real scenarios. First, you would need to educate your market that they need to
care about the CAP theorem and what that is, that Rethink was damn good CP and
that while Mongo might be fast, it isn't correct.

~~~
sikan
Why not call them out then? It should take only one or two blog articles to
explain why mongodb benchmarks are bogus. I fail to believe it is hard to
teach some database knowledge (CAP and others) to your potential customer when
they are developers. Heck, it would even boost your SEO by a ton.

------
reactor
Excellent reflection, I think he forgot the 'elephant' in the room. Whenever I
wanted to choose between Nosql solution, I always come back to Postgresql,
just enough to fit my limited usecases.

------
alexandercrohde
As somebody squarely in your target audience (sr software engineer with major
respect for databases done correctly and no respect for anything like mongo)
let me give my perspective.

A) I have no idea what makes rethink db better than mysql off the top of my
head (maybe stuff exists, but I don't know what it is. I also am risk-averse
and don't really have any major complaints with mysql).

B) I understand there are a lot of database technologies out there (mysql is
always improving, people speak highly of postgres, people keep mentioning this
maria DB thing, etc) which leads to a decision fatigue. It's much in the same
way that if I have to choose between learning 3 frameworks, I'll just use none
and see which one dies first because I'm optimizing for not learning dying
technologies.

So unfortunately it comes down to marketing, which is a disappoint to anybody
who wants to believe the best products will market themselves and win out.
Sorry betamax.

------
grizzles
Nice article. I think he's underestimating the failure on the sales team. They
needed to find the intersection of Oracle customers and customers that needed
the unique OLTP features of their product. I would have tried to bring an ex-
Oracle guy on, for example, someone who's sold into finance or healthcare.

~~~
cobookman
Healthcare and finance firms run conservative IT departments and you'd be
unlikely to get them as the first customer.

------
SadWebDeveloper
TBH i never heard about RethinkDB until they announce they were closing... it
look solid but never heard from them, probably because from my POV, the
database choices gets pushed by communities more than "educated developers"
like for example, python devs like to to push postgresql over anything else,
nodejs devs like to push mongodb over anything else, php devs like to push
mysql over anything else, aspnet/c#/paste-any-ms-languanges-on-win32 like to
push sql server over anything else and oracle was there before anything else
(so pretty much everyone knows it), my point is that maybe RethinkDB needed a
community niche that push the db rather than being the second choice for every
community.

------
ubercore
Man, I would have loved to pay for RethinkDB. Granted, the blame lies on me
here, but something I was disappointed to see the first point not acknowledge
that RethinkDB didn't really ask for money. I mean, I don't know if they
changed it after folding, but go the site and tell me how to pay for it.

I would have paid a licensing fee to continue using it, but we've taken the
time to switch over to Postgres now.

EDIT: Also, re: metrics of success, the examples listed as wrong there are
_exactly_ why I enjoyed the product and was willing to invest time learning
and implementing in a relatively new technology.

~~~
rspeer
On the other hand, I understand why most developers wouldn't pay "even the
price of a Starbucks coffee" for the product: because paying anything as a
developer is hard. It requires making the case for why you need it to other
people in the company. Developers aren't usually in a position to make
financial decisions on a whim, especially those where the cost will probably
grow in the future.

~~~
mikekchar
I think this is right on the money. As a vendor, you have to understand who
your users are and who your customers are. In this space, they are different.
Just look at the number of developer tools that are "free for non-commercial
use". Developers don't pay for tools. Companies pay for tools that they are
convinced they can't get any other way.

They didn't have a poor market; they didn't have any market at all. If I'm the
CTO of XYZ, explain to me what I'm buying. I hate to keep coming back to it,
but that's what Cygnus did so brilliantly: "You need an embedded development
system. The existing solutions do nearly what you want. Pay us slightly less,
and we will make GCC do _exactly_ what you want." I know what I'm paying for.

"Build it and they will come" does not work in the open source space --
because if you have already built it, they don't need to pay you. And if you
haven't, then they don't want it.

Now, if they had built a DB similar to Mongo and then sold a service that
migrated people off of failing Mongo installations and onto RethinkDB, then
they would be on to something. Tired of having your DB chew your data for
breakfast? Want to have your reports finished the same day you ran them? For
the price of a single developer, we will fix all your problems by migrating
you to RethinkDB. That's something that will make money.

But who wants to charge for services? How will we get our multiples if we only
charge once for our work? That's just folly!

------
overcast
I started a new project in RethinkDB over the weekend, and this postmortem
makes me want to start my next one in it even more so. It really is exactly
what I want in a database. Relational document storage, with a sql like
language, and realtime change feeds. Who WOULDN'T want to use that?!

------
mdani
The database will never sell itself. You need use cases - even Oracle sells
sofware solutions for ERP, CRM and SCM which come bundled with a Oracle
database. Microsoft SQL server is another example of bundling. So use cases
come first before correctness, consistency or excellent SQL.

------
codinghorror
Excellent retrospective. I know these are painful to write, so thank you.

------
throw2016
I think the basic problem here is a lot of technology is heavily hyped and in
use but 'not in use'. People are learning about them, trying them, even trying
or using them in small internal deployments but are not buying them or
supporting them in any way.

Those who take them into production are startups who are themselves trying to
succeed or large companies who have tons of engineering talent who can create
the product if need be but since its open source and available they use the
open source version but they don't value it. Think the recent article where
Github, forget supporting Redis has not even reached out to the developer once
to thank him.

The demands of the community are high touch, even one or two weeks without
commits and people start getting restive and raise 'alarms' on github and
here. If there is potential value that you are still figuring out how to
capture and a lot of attention you could end up expending time dealing with
the politics of a fork. On the other end purchase decisions of most companies
brings a whole new sets of requirements from internal processes, approvals,
policies to decision makers and most open source companies do not have the
resources or experience initially to manage the expensive and high touch sales
and marketing process that most companies buying technology require.

If you have funding the pressure is even higher. There is a missing piece of
how to translate support and usage of open source software for commerical
reasons into some sort of revenue even minimal without friction. I think there
should be a spotlight on companies using open source and their support and
contribution back, and not just acquiring projects or hiring their developers
which is an 'influence play'.

------
trevmckendrick
The Economist comment came out of the blue. Why does the author believe that
will help one improve?

~~~
hueving
It helps you view things through the lens of market forces. Most regular media
is just pundits channeling some moral position based on the writer's politics.

~~~
zigzigzag
The Economist is basically pundits channelling their personal politics these
days too. Sadly. I used to enjoy reading it a lot more than I do these days.

I don't think The Economist is what to read for this situation though. A book
on the history of Oracle or something might have been more appropriate.

------
antman
Good ideas but as an outsider that wanted to use it this was my takeout:

If I look at google trends [0] mongodb starts trending July 2009 (It exists
earlier but it is the time that rises) rethinkdb equivalent is March 2015 and
it never rises so steeply. That is six years.

With all the people I've talked nobody new rethinkdb it and it was not a
problem of re-educating them on its merits. So what was needed was marketing,
success stories and competitors' failure stories.

People did not know it existed. Maybe in the cognitively saturated NoSQL
market we more. Gone are the days we could predict developers' needs on our
hunches or our interpretations of the feedback we are given from early
adopters because they are a biased sample.

Worse: we might need people in marketing and, god forbid, some MBAs.

[0]:
[https://www.google.com/trends/explore?date=all&q=rethinkdb,m...](https://www.google.com/trends/explore?date=all&q=rethinkdb,mongodb)

------
redslazer
I always liked the concept of rethink db and I tried to get started with it a
couple of times but in the end I just wanted to get my project(s) out of the
door as quickly as possible.

This to me explains the massive success and quick rise of things like redis,
mongodb etc. Sure the defaults are insecure but they work and they work
immediately.

------
Zak
As a user of databases, I've been shocked by MongoDB's popularity in light of
its apparent disregard for correctness and reliability. I used it once to
cache a processed form of some data that could be regenerated. One unclean
shutdown and it lost that data. I tried using some of the provided recovery
tools and failed to recover the data.

That was it. Every time MongoDB has come up in conversation since, I've said
"Mongo eats your data" and recommended another solution, even though I'm
pretty sure that particular bug was fixed long ago. _You had one job,
MongoDB_.

I see this as equivalent to a company marketing a smartphone with an
impressive feature set and a high rate of bursting in to flames. Most owners
would return their recalled phones and think twice about buying the next model
from that manufacturer.

------
rumcajz
I love the postmortem culture and it's great to see people writing postmortems
even when they don't have to. It would be nice to get to a point where
postmortem is something that occurs naturally, with people expecting it and
getting confused and asking questions if it didn't.

One can even imagine a future where each court case is followed by a
postmortem. Possible bullet points:

1\. Was this an actual problem? Did anybody get hurt? If not so, what's wrong
with the law? How should we fix it?

2\. What were the ultimate causes of the problem? Ok, A killed B, but why?
Could it have been prevented?

3\. What are the action items to prevent this exact scenario from happening
again? Who's assigned to each action item? What's the deadline for the item?

------
manigandham
What was the actual go to market strategy? Selling to enterprises? They have
the money to spend but it seems like there was never an enterprise version of
the software itself with features that are paid only. This is the high-margin
sales that database companies build on, and then perhaps offer cloud and
managed service to capture more spend. Support plans can also be great
revenue, although they're not a sales driver but rather just required for big
companies and likely break even for smaller ones.

That being said, it's an interesting database and I'm still looking for a
solid distributed OLTP document-database with SQL/joins and multi-cluster
replication... maybe someone else will try again.

~~~
williamstein
I was told (by their lead engineer) a few weeks before RethinkDB shut down
that they _did_ have an enterprise version of the software with features that
are paid only. However, clearly, that product introduction was too little too
late.

------
niftich
If your target market is enterprises who are willing and able to pay, isn't it
paramount to get into some market analysis firm's ranking quickly as a
"leader", like Gartner's Magic Quadrant?

On this very busy Quadrant (which ought to be a clue too) from October 2015
[1], I don't see RethinkDB at all, while many other niche players are present.
This to me indicates that somehow, somewhere, not enough press was generated
on RethinkDB, and it was largely unknown to the sorts of decision-makers who
decide what products to evaluate down the road.

[1] [http://imgur.com/a/PyR57](http://imgur.com/a/PyR57)

------
robot
I really appreciate the time and effort to share such an analysis. I disagree
with the perspective that users think the product is in the open source tools
market. Open source tools market is where the company ends up as a consequence
of the product not being compelling enough for a commercial use case.

5-6 years ago I thought wow this is a really complicated product (a better
database?) and I hope they pull it off as a startup.

IMO the biggest issues are (a) a database is a complicated product and (b)
there are many options that are good enough and stable. You have to do 10x
better than the status quo and that is very hard to do in a space where
products are complicated.

------
jondubois
I fully agree about the developer tools space being very difficult. I have a
popular open source project but was never able to monetize it (and I've had
plenty of time and tried a few different things). I can fully relate to this
article.

Having a popular OSS project helps me a bit when getting job opportunities but
that's all... Even if you considered me as a single-person team and counted
'better job opportunities' as a return on my investment, I don't think the
increased salary even comes close to getting me a ROI on time spent.

OSS is a terrible investment. It's like buying a lottery ticket.

------
netham91
"Unfortunately you're not in the market you think you're in -- you're in the
market your users think you're in." This is so simple but easy to miss advice.

------
ambirex
If you are a developer and build a product using react. When do you ask the
business to buy support?

While you're building you assume you'll have to gain your own level of
proficiency. So you don't know at what point you'll need support.

Having to go back and ask for an increased budget after it has shipped is a
harder internal sale.

As much as I appreciate rethink's approach, I can see it as a challenging
business to be in

------
hardwaresofton
This is the most useful postmortem I have ever read.

Thanks to the RethinkDB team and Slava for everything they've done over the
years, and for making RethinkDB open source, I continue to use it in my
projects.

While it might have ultimately lead to your demise, thank you for valuing
correctness, simplicity, and consistency. I've never seen another document
story company get things so right.

------
linuxhansl
It's hard to sell something as low level as a database. For a startup there
needs to be a specific itch to scratch, an itch that many potential customers
experience frequently.

As a systems-guy (more or less) I find that frustrating, but I have seen many
times that this is so.

It still worth having the courage to try and these guys did that. It could
have worked. Hats off.

~~~
v3ss0n
For us , its working very well and stable!

------
sandGorgon
Hosted db is the way to go. Just as a perspective - this is 2017. How many
multi-AZ, failover tolerant, hosted postgresql offerings do you know of?

RDS, Heroku and Compose. Google and Azure still dont do hosted postgres.

So many people pay for Dynamodb. You could be an alternative.

The point is - rethinkdb still exists. you could still do it. via preorders on
Kickstarter.

~~~
jpalomaki
It's much lower barrier to buy managed database service from Amazon or
Microsoft than from a start-up.

They have the credibility. You don't question if these companies really have
the people to keep the stuff running. In many cases the customers also already
have a billing relationship with them. Much less friction to just add one new
service to the already quite big invoice vs buying from a different company.

Competing with AWS or Google is hard, they would be still making money on the
infra even if they gave the managed database out for free.

~~~
sandGorgon
compose is a startup. heroku was a startup when they started. in fact, if I
have my timeline right then heroku managed postgres preceded RDS
([http://www.zdnet.com/article/heroku-launches-cloud-
postgres-...](http://www.zdnet.com/article/heroku-launches-cloud-postgres-
database/) \- 2011 versus
[https://en.wikipedia.org/wiki/Amazon_Relational_Database_Ser...](https://en.wikipedia.org/wiki/Amazon_Relational_Database_Service)
\- 2013)

Rethinkdb is an incredible architecture. If I was in the market for something
like rethinkdb/dynamodb, I would completely go with something that is built by
the original inventors.

Just like docker for example.

~~~
Artemis2
Heroku was acquired by Salesforce in 2010, Compose by IBM in 2015 though.

------
bryanlarsen
While I think @coffeemug's analysis is good, I think it glosses over the core
issue: money.

rethinkdb's core issue IMO was that they took VC money, which did two things:

\- mandated that success had to be a home run

\- gave them a fixed runway

Sure, rethinkdb made some mistakes, but I think those were successfully
corrected. The problem is that those corrections were too late and they ran
out of runway, and the success looked more like a triple than a home run so
they couldn't go back to VC's for more.

Of course, not taking VC would have slowed things down even more, but that's
fine. The primary attribute many look for when choosing a database is trust,
and trust takes years to earn.

mongodb vs rethinkdb is very comparable to mysql vs postgresql, and I think
the final results will turn out very similar. mysql did very well and was the
leader for a long time, but today postgresql is the clear favorite.

------
willyk
Thanks to Salve for writing an incredible retrospective. One thing I'd be
curious to hear is whether the RethinkDB team feels they could have create the
tool and potentially the company without taking on venture capital/investors
(similar to PostgresSQL, which I don't think has taken on vc).

~~~
SamReidHughes
That would have been completely impossible.

------
wedesoft
I have used RethinkDB and must say this is one of the most polished pieces of
software I have ever used. The only think I am wondering is, whether the
project could have moved faster if it had not been implemented in C++.

------
desireco42
I really can't read all this negativity. Seriously you guys need to snap out
of it. You created something fantastic, a database that perfectly answers need
of developers. Clearly you need to give it time and align your expectations
with market.

RethinkDB is fresh view on how databases can work and look, it provides level
on goodness not seen before. Just continue building on it. Horizon is also
awesome. Things don't happen overnight.

~~~
elgenie
You're saying that they succeeded at creating a good database. The author
seems to agree. The author is saying that they failed at creating a viable
business.

The postmortem is about why the former didn't lead to the latter.

------
platinumm
A very good read,many lessons learned. Marketing and software development are
two different almost opposite skills.One goes up other goes down.

------
Walkman
> "how is RethinkDB different from MongoDB?" We worked hard to explain why
> correctness, simplicity, and consistency are important, but ultimately these
> weren't the metrics of goodness that mattered to most users.

So everybody is crying how shitty and unreliable MongoDB is, but this is
exactly what makes them successful? Very interesting!

------
daxorid
Anecdotal data point of one: the primary reason we decided not to use RDB
after our evaluation was performance. Queries over even small data sets, with
secondary indexes, were painfully slow.

We really wanted to believe in the idea, but the implementation left much to
be desired.

------
palerdot
Totally off topic - In mobiles, tables are stripped off while the rest of the
content is responsive. There is no scroll bar and no way to read the data
given in the table from mobile. Hope Github fixes it.

------
jldork
Yeah, my perspective is that Mongo just positioned themselves well in their
marketing. They became a default option as part of the MEAN stack.

I wonder if Rethink somehow piggybacked on React or Angular in the same way...

~~~
amalag
A part of their success was timing. When they came out I didnt know of
anything else that could allow you to store JSON objects and do queries on
them. Just that ability was a big deal. I believe the mainstream alternatives
was to serialize your JSON object and store it in a text field.

------
voiceclonr
Grim read, but fantastically put together. Thanks for writing it up.

------
dsun184
So which reactive database should we use now? RxDB? Firebase?

------
inconclusive
On reasons why RethinkDB failed, add: not having SQL support.

------
ai_ja_nai
The link is broken

------
jackielii
measure before optimise

