4 ms·
I think Rethinkdb although having quite a lot of ambition and delivering on a lot of that ambition just wasn't compelling enough compared to the strides made by
by gamesbrainiac 10y ago
I think Rethinkdb although having quite a lot of ambition and delivering on a lot of that ambition just wasn't compelling enough compared to the strides made by competitors.
One example I keep referring back to is postgres. Postgres is soon going to be getting distributed capabilities, and I think it corresponds to the need in having highly available systems.
Now, this was what was missing from postgres all along as postgres already has LISTEN/NOTIFY, so if you slap on a system that can properly replicate and shard it, then what you have is a product that is open source, free and has years of strong engineering to back it up.
Its hard to compete with that.
- phamilton 10y agoRethinkDBs changefeeds were a lot more powerful than LISTEN/NOTIFY. Some of it is just nicer abstractions (like limit/offset changefeeds, where you get notified if say a high score list changes). But there are a bunch of subtleties in that space that RethinkDB had to solve. Like enabling you to fetch the existing results and receive the new ones without gaps or duplicates. RethinkDB 2.0 didn't have that, but 2.1 added it. They had to iterate many times to improve the changefeed semantics, and to get LISTEN/NOTIFY to the same place you'd have to solve a lot of those same problems.
- williamstein 10y agoIt is true that there were a huge number of subtle issues with exactly what you're describing above (involving changefeed semantics). Many of the RethinkDB bugs I reported (all of which the team fixed!) were related to these edge cases, which I hit when pushing things hard in production. RethinkDB is amazing in a way that is not interesting to an academic researcher, but matters very much for production use. I really, really hope a couple of key people realize this so that RethinkDB can have a second life as an open source project without a company home.
- phamilton 10y agoUnder a successful support driven model, engineering costs associated with fixing bugs and quirks in the product are amortized across all clients. Fixing a bug for one user fixes it for another, as well as future users. However, if the paid user base is not sufficient to cover support costs, VC money is effectively subsidizing support. In the spirit of analyzing your business model, how much of your success has come about because you had access to a subsidized team fixing bugs for you?