Live data from Hacker News

RethinkDB Postmortem

github.com

151–160 of 270 posts

Re: RethinkDB Postmortem

#151

Earlier quoted context omitted.

The thing is, the modern systems are often less complex. SQL databases are generally far simpler than MongoDB - you just need to learn relational algebra rather than blindly shoveling whatever JSON you got into the DB. As for Java + async + threads, I use Akka and it's basically seamless. But Netty + core Java Executors is fine too, just more verbose.

> you just need to learn relational algebra rather than blindly shoveling whatever JSON you got into the DB. No SQL per se is not hard. But the whole data modeling, creating tables, picking types is just needless bureaucracy Yes, I want to save a json snippet and be done with it. I don't want to create another table because I have a 1-N relationship. And while ORMs make this easier it is still not painless

Schema-less data always sounds good in the beginning until you actually try to use that data. Then you end up encoding all the validation and data munging logic into whatever process reads from it.

An internally-schema'd database just recognizes that this is absurd and lets you put the bottom three layers of validation logic inside the database, where you only have to do it once.

Re: RethinkDB Postmortem

#152

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 instan…

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

Re: RethinkDB Postmortem

#153
post #92

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.

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

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

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

Re: RethinkDB Postmortem

#154

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 dat…

Re-licensing is working on by Intermin leadership team. We are also waiting for the results. Hopefully it will be Apache or MIT Licensed.

source : https://docs.google.com/document/d/1f8qODp7voKIqwioQ3si69q3-...

Re: RethinkDB Postmortem

#155
post #69

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.…

Don't forget the proliferation of electron so no one has to learn a new language and desktop toolsets. Just for kicks I wrote a desktop todo list in GTK and C, not tools I had extensive knowledge of ever and nothing recently. It was a breath of fresh air how simple it was compared to doing the same in modern frameworks. A single ~30 line function to create the gui and the rest held together with a couple of function…

But is it cross-platform (Win32, Windows UWP, OS X, multiple linuxes, iOS, Android) and most of that same code works on the web?

It's okay to bemoan Electron for being bloated but multiple balls have been dropped by OS and platform makers, GUI toolkit makers, language runtime makers, and that giant amount of missing glue inbetween, to get to where we are.

It's rather sad that Electron, out of all things, is the first thing to fulfill the holy grail of write-once, run anywhere, in a way that's good enough and palatable to the plurality of users' and devs' satisfaction.

Re: RethinkDB Postmortem

#156
post #24

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 dat…

I'm also interested to hear what the future, if any, looks like for RethinkDB. Would also be very curious to explore what can be done regarding the IP/licensing as part of that future (agree with the concerns mentioned here).

RethinkDB as a product is not dead yet, you can contribute in it. Re-Licensing attempts are already in progress , ex founders had to deal with legal issues for it so it will be long.

Re: RethinkDB Postmortem

#157

Earlier quoted context omitted.

> you just need to learn relational algebra rather than blindly shoveling whatever JSON you got into the DB. No SQL per se is not hard. But the whole data modeling, creating tables, picking types is just needless bureaucracy Yes, I want to save a json snippet and be done with it. I don't want to create another table because I have a 1-N relationship. And while ORMs make this easier it is still not painless

Schema-less data always sounds good in the beginning until you actually try to use that data. Then you end up encoding all the validation and data munging logic into whatever process reads from it. An internally-schema'd database just recognizes that this is absurd and lets you put the bottom three layers of validation logic inside the database, where you only have to do it once.

> Then you end up encoding all the validation and data munging logic into whatever process reads from it.

Do you think that doesn't happen in regular DBs or that schemas don't evolve?

Love for static typing is basically Stockholm's syndrome

Your system will eventually end up with a fixed schema, but until you get to that place you don't need to "stop the world" to change it. "But Postgresql can add columns without downtime" yes it can, but what about your system?

Re: RethinkDB Postmortem

#158
post #11

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…

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…

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.

Re: RethinkDB Postmortem

#159

Earlier quoted context omitted.

I've read the Economist for the last 20 years and the HBR for a few months before I dropped it. The Economist offers insight, thoughtful analysis and writes about the world: literally but also politics, culture, and science. The obituary is surprisingly fascinating for instance. You may not always agree with its position, but you know that their position will be worth engaging with and thinking about. No, I don't wor…

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

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

Re: RethinkDB Postmortem

#160
post #69

Earlier quoted context omitted.

Don't forget the proliferation of electron so no one has to learn a new language and desktop toolsets. Just for kicks I wrote a desktop todo list in GTK and C, not tools I had extensive knowledge of ever and nothing recently. It was a breath of fresh air how simple it was compared to doing the same in modern frameworks. A single ~30 line function to create the gui and the rest held together with a couple of function…

But is it cross-platform (Win32, Windows UWP, OS X, multiple linuxes, iOS, Android) and most of that same code works on the web? It's okay to bemoan Electron for being bloated but multiple balls have been dropped by OS and platform makers, GUI toolkit makers, language runtime makers, and that giant amount of missing glue inbetween, to get to where we are. It's rather sad that Electron, out of all things, is the first…

Electron certainly isn't the first thing to give "write once, run anywhere", let alone good enough to satisfy users. I groan every time I download an app only to discover it's Electron based.

Java beat Electron to write-once-run-anywhere by a couple of decades, and still does in the sense that Electron requires you to make platform-specific builds of your app even if the core code is the same (Java gives you that option but doesn't require it, you can still distribute a jar or web start file).

Meanwhile, Electron has managed the feat of being even bloatier than Java is. The DOM was never designed for GUIs and the terrible performance of web and Electron based apps is a testament to that. At least Java apps tend to have meaningful menu bars and context menus.

Electron satisfies web devs who have either never written desktop apps in other frameworks, or did decades ago and think nothing improved there. They "satisfy" users in the sense that users are rarely offered any alternative so have to suck it up and tend to judge web apps against each other vs a well coded, tightly written desktop app (office suites being a notable exception).

Post reply on HN