20 ms·

RethinkDB Postmortem

• hkailahi 10y ago
  I'm surprised there are no comments here, this is the best thing I've seen on HN in a while.
  • andrewwhartion 10y ago
    I'm still meditating on the advice given. Perhaps a moment of silence for a fallen comrade...
  • sytse 10y ago
    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 10y ago
      Thanks for your insights on this postmortem Sytse. Love how you are leading Gitlab.
  • agibsonccc 10y ago
    I'll attempt to add to this. I might be stating things that are a bit controversial here. 1 thing we are always transparent with users about is how our business model works. 1 of my favorite videos on the internet about this is [1]. We are very much based on closed source for making revenue. This has actually helped with our community a lot. We are basically focused on closed source solutions for specific verticals. The only way to get clients to pay is to make something more efficient or don't open source/core it. For open source companies there is always a trade off of community vs customers. You have to find a hard line and stick to it. Community is great, but most of those people won't want to pay you. You can try to convert them, but that takes a lot of time and isn't the best path to market. We strive to provide a great base line experience to our users, but a few of the things we have found in practice that helps: 1. Features have customer names on them 2. There's a mass of community interest in a specific feature You have to be careful about where time is spent. It's very easy to mistake "users" for "customers". I wish slava and co the best of luck and really appreciate their post mortem. 1 thing we've learned as an infra company is "be as close to the app as possible". In our case the bulk of what we focus on is banking/telco anomaly detection. It's a straight forward revenue making product that can benefit from deep learning. The great thing is we can grow in to other use cases later on if we find something else interesting to work on. [1]: https://www.youtube.com/watch?v=6h3RJhoqgK8 https://www.youtube.com/watch?v=6h3RJhoqgK8
    • flukus 10y ago
      > 1. Features have customer names on them Even seen this backfire at many commercial companies. Adding whatever features a company is willing to pay for will often pull a product in multiple, incompatible directions.
      • agibsonccc 10y ago
        I'll give you that. In my case, a lot of what we do is look for numbers and how well it fits our main application area. You definitely have a valid point here though. That actually goes hand in hand with "users look like customers". Also: "Not every customer is a good customer."
• redslazer 10y ago
  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.
• StavrosK 10y ago
  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.
  • dboreham 10y ago
    Rethink, Mongo et al are scalable (at the expense of some ACID). PG is certainly a good DB (I use it in production) but it is at heart a traditional RDBMS - not designed for scalability. Apples vs Pears..
    • hoodoof 10y ago
      What do you mean pG isn't designed for scalability? Its SMP scaling is incredibly good, close to linear.
      • manigandham 10y ago
        Postgres neither scales vertically or horizontally. v9.6 finally brought some parallel scans but is still limited in scope and far behind the commercial databases. Same with replication and failover, although there are decent 3rd party extensions to get it working.
        • anarazel 10y ago
          I suppose the parent comment was more about scaling up for transactional workloads - the story there is a lot better (although there's still issues left we haven't tackled, but mostly on very big machines) than for analytics workloads. But yes, while we progressed in 9.6, there's still a lot of important things lacking to scale a larger fraction of analytics queries.
• karlunho 10y ago
  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 10y ago
    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.
  • luhn 10y ago
    > especially if your are reducing your computer pricing slower than Moore's law I agree with most of your comment, but I take issue with that last part. Moore's law has no relation to the price of computing. It only makes predictions on the number of transistors in a CPU, not the performance of the CPU nor the price/performance ratio of the CPU. Even if it did, compute costs much more than the CPUs; memory, disk, power, cooling, networking, enclosures, and more all cost a significant amount relative to the silicon. I know Google Cloud declared they were going to decrease prices at pace with Moore's law, but even if they can deliver on that it will be through innovations outside of the CPU.
  • sah2ed 10y ago
    Actually, I think learning to understand how these (complex) market forces come into play is exactly why Slava added the recommendation to religiously read The Economist at the very end of the article for maximum effect.
• Perceptes 10y ago
  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.
  • runeks 10y ago
    > 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. This world is always willing to wait, it was the RethinkDB team and/or their investors who weren't. The world will wait for you in eternity; it's just not willing to provide you with capital during the wait. Your statement makes sense if there were a dozen competitors in the database space. With hundreds of competitors, actually evaluating them all becomes more expensive than just choosing eg. a managed SQL solution and then switching provider if it doesn't live up to its promises. That's so much more flexible from a business perspective than evaluating a hundred different open source database systems, settling on one, and then having to rewrite your database code when the database you've chosen ceases development, and you're left as the maintainer of it.
  • harryh 10y ago
    Yes, worse is better. https://www.dreamsongs.com/RiseOfWorseIsBetter.html https://www.dreamsongs.com/RiseOfWorseIsBetter.html
  • andrewbarba 10y ago
    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/
• bcantrill 10y ago
  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-perspective https://www.joyent.com/blog/samsung-acquires-joyent-a-ctos-p...
• hoodoof 10y ago
  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 10y ago
    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 10y ago
      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.
• codinghorror 10y ago
  Excellent retrospective. I know these are painful to write, so thank you.
• haddr 10y ago
  I don't get this: "Read The Economist religiously. It will make you better faster". Anybody could explain?
  • reactor 10y ago
    It should come as no brainer, the back bone of any business is 'supply and demand', while it may sound simple, it is increasingly becoming complex and understanding the new world economics helps to grow the business and 'The economist' seems to serve lot of insights.
  • hackcrafter 10y ago
    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.
• ambirex 10y ago
  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
• trevmckendrick 10y ago
  The Economist comment came out of the blue. Why does the author believe that will help one improve?
  • hueving 10y ago
    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 10y ago
      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.
• jackielii 10y ago
  measure before optimise
• grizzles 10y ago
  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 10y ago
    Healthcare and finance firms run conservative IT departments and you'd be unlikely to get them as the first customer.
• willyk 10y ago
  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 10y ago
    That would have been completely impossible.
• reactor 10y ago
  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.
• overcast 10y ago
  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?!
• vii 10y ago
  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.
• coffeemug 10y ago
  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.
  • creativityland 10y ago
    Thanks for pointing that out, just noticed the "/_drafts/why-rethinkdb-failed.md".
  • boulos 10y ago
    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.
• dkarapetyan 10y ago
  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 10y ago
    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
• ubercore 10y ago
  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 10y ago
    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 10y ago
      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!
• sikan 10y ago
  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 10y ago
    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 10y ago
      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.
  • roel_v 10y ago
    "All you had to do was aggressively market yourself as the better option by directly comparing yourself to it." Lol. "It's not hard to win an Olympic medal in the 100m sprint. All you have to do is move your legs faster than those other guys!"
    • sikan 10y ago
      But they were and still are better than mongodb? They already achieved that ?
• mdani 10y ago
  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.
• linuxhansl 10y ago
  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 10y ago
    For us , its working very well and stable!
• manigandham 10y ago
  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 10y ago
    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.
• yummyfajitas 10y ago
  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.
  • davidw 10y ago
    Interesting idea, but perhaps it's also possible to look at it as the industry broadening. 40 years ago, you had to be pretty knowledgeable to get anything at all done with computers. These days, it's possible for more people to do things, and yet there's still a market for people who are deeply knowledgeable. A lot of people don't care much about the tech, and just want to build something. If easier (for them) tech lets them, that's a win, no? Of course... that's easy to say but harder to swallow when they end up building something, making some money, and then hiring a developer to clean up their hideous mess. I've been there too.
  • deleted 10y ago
    [deleted]
  • lelandbatey 10y ago
    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.
• sandGorgon 10y ago
  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 10y ago
    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 10y ago
      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-database/ http://www.zdnet.com/article/heroku-launches-cloud-postgres-... - 2011 versus https://en.wikipedia.org/wiki/Amazon_Relational_Database_Service https://en.wikipedia.org/wiki/Amazon_Relational_Database_Ser... - 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 10y ago
        Heroku was acquired by Salesforce in 2010, Compose by IBM in 2015 though.
• atnnn 10y ago
  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 10y ago
    Thank you very much @atnnn for continued keeping RethinkDB alive.
• desireco42 10y ago
  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.
  • huckyaus 10y ago
    > Just continue building on it. You say this as though they weren't fresh out of money, energy and competitive advantage.
  • v3ss0n 10y ago
    The opensource effort is continuing although slowly , it have almost-daily commits. We need more users and contributors.
  • elgenie 10y ago
    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.
  • desireco42 10y ago
    To answer detractors and well meaning commenters. I understand the challenges, just this project have to go on.
• joshberkus 10y ago
  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 10y ago
    Why is optimizing for SSDs nonsense? Empirically this seems correct since RethinkDB themselves pivoted away from this but curious about the technical explanation.
    • Plugawy 10y ago
      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 10y ago
        Exactly.
    • dkersten 10y ago
      RethinkDB themselves pivoted away from this I believe the storage backend remained largely the same (ie current RethinkDB, IIRC, is still optimised for SSD). Maybe I'm mistaken.
      • SamReidHughes 10y ago
• alexandercrohde 10y ago
  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.
• robot 10y ago
  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.
• jwr 10y ago
  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.
  • boubiyeah 10y ago
    Agreed, there is still a market for that imo. couchDB has it, but it's so slow :( Right now if you want a good DB and a pubsub/notification/streaming capability, that means either increased latency (polling the DB in your application layer and handle the notifications there) or using another dedicated system (kafka, redis, etc) with all the added complexity that introduce :(
  • amelius 10y ago
    > 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. Have you looked at Datomic? It's not free but I think it provides the functionality you are looking for.
    • jwr 10y ago
      Yes. In fact it would fit my app very well, because it's also written in Clojure, and I'm even using datascript on the frontend side. But "$5000 per Year per System" is outside of my price range for the foreseeable future.
  • doczoidberg 10y ago
    firebase is also a realtime json database. I am quite satisfied with it till now
• rumcajz 10y ago
  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?
• spullara 10y ago
  I'm the Series A investor in FoundationDB, met with RethinkDB really early on, and really appreciate your post.
• lvca 10y ago
  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 10y ago
    > 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 10y ago
      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.
• v3ss0n 10y ago
  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-ruc7h3ncfH0KoHYv_4k/ https://docs.google.com/document/d/1f8qODp7voKIqwioQ3si69q3-... 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_JiUmpIGkbwJOgVL8T7nW0sPz7OJZjro https://docs.google.com/document/d/1c27S3Ij2WLB_JiUmpIGkbwJO... 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 .
  • smhg 10y ago
    First of all: this is great, thank you so much! Secondly, and with the risk of hijacking the OP: I think it would be a good thing if you could put a status update either on rethinkdb.com or ~the first paragraph of the readme on GitHub about what you are trying to accomplish related to the name/rights/ownership/license/... I check those about once a month to see if something has changed. As a current user and someone evaluating future usage, this is causing the most uncertainty. I don't know how these things happen (it is probably complex). But I want to commit. Even if progress is slow. Bugfixes are important, but secondary if the project might somehow be significantly damaged trying to "escape" its current ownership. As an example: you are trying to transfer ownership of the build tools? I understand that might take a while, but what if that somehow can't happen? Is recreating them realistic? Basically a list of threats/risks would be nice to have! :) EDIT: this is also relevant for contributors/donations/... any type of investment. Thanks again!
• Walkman 10y ago
  > "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!
• kriro 10y ago
  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.
• sontek 10y ago
  > 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 10y ago
    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,
• mstipetic 10y ago
  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.
• platinumm 10y ago
  A very good read,many lessons learned. Marketing and software development are two different almost opposite skills.One goes up other goes down.
• antirez 10y ago
  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 10y ago
    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.
    • dkersten 10y ago
      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. That's latency, not correctness. I think even "social startup of the year" cares that the post shows up at all, is attributed to the correct author, isn't corrupted somewhere and so on. Data correctness/consistency is about making sure that the data isn't in an inconsistent state.
• inconclusive 10y ago
  On reasons why RethinkDB failed, add: not having SQL support.
• antman 10y ago
  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,mongodb https://www.google.com/trends/explore?date=all&q=rethinkdb,m...
• throw2016 10y ago
  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'.
• Zak 10y ago
  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.
• niftich 10y ago
  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
• netham91 10y ago
  "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.
• palerdot 10y ago
  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.
• daxorid 10y ago
  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.
• notacoward 10y ago
  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 10y ago
    > 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
  • sah2ed 10y ago
    > but he introduced me to the concept of market vs. technical risk This bit alone provided the right keywords to help me express some of the ideas in the essays I have been writing. Thanks for posting.
• bryanlarsen 10y ago
  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.
• jldork 10y ago
  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 10y ago
    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.
• dsun184 10y ago
  So which reactive database should we use now? RxDB? Firebase?
• SadWebDeveloper 10y ago
  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.
• wedesoft 10y ago
  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++.
• ai_ja_nai 10y ago
  The link is broken
• hardwaresofton 10y ago
  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.
• cryptica 10y ago
  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.
• voiceclonr 10y ago
  Grim read, but fantastically put together. Thanks for writing it up.