Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

RethinkDB Postmortem

github.com

Post reply on HN
Print view View original

11–20 of 270 posts

Re: RethinkDB Postmortem

#11

Post by 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.

Re: RethinkDB Postmortem

#13

Post by dboreham »

karlunho wrote: post #7

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

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.

Re: RethinkDB Postmortem

#15

Post by 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

Re: RethinkDB Postmortem

#17

Post by rogerbinns »

bcantrill wrote: post #10

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…

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

Re: RethinkDB Postmortem

#18

Post by brightball »

StavrosK wrote: post #5

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…

That's been my experience as well. Postgres handles everything until you hit an edge case on some of your data (volume writes with scale out, performance critical advanced functionality, heavy BI work with huge datasets, etc).

When you hit those edge cases or specific needs, you implement the specialty solution. Most people never come close to those edge cases though. When they do, PGs foreign data wrappers make the adjustment as smooth as possible.

Re: RethinkDB Postmortem

#19

Post by adsharma »

bcantrill wrote: post #10

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 wish more databases were developed with modular, reusable pieces. RocksDB is already a popular storage engine for anyone building a database today. Throw iterlib[1] (shameless plug) on top of it, you get a query API for free.

Now you get to innovate on top of these modules using reactive APIs, user space TCP, Fancy serialization, Standards compliant SQL etc.

Some of the current incumbents were written in the 90s when C++ was a different programming language, which hurts innovation.

[1] https://github.com/facebookincubator/iterlib

Re: RethinkDB Postmortem

#20

Post by btown »

StavrosK wrote: post #5

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…

I was truly hoping that RethinkDB would be the Mongo that Mongo could have been: a NoSQL database, but one with joins; a NoSQL database that is actually CP [0]; a database that comes out of the box with granular real-time updates (so you don't even need to worry at first about the extra moving parts of a Redis server or other queue). For a business starting from scratch with those needs, I'm making do with Mongo, but I was anxiously waiting for RethinkDB to get more battle-tested... alas, it wasn't meant to be. And I fear that we'll be stuck with Mongo for quite a while.

The truth is that NoSQL has great promise, but the folks with actual money to spare today are the ones who want a better SQL database, because they can afford the tradeoff of development time for reliability that SQL administration and migration provide. And people who solve the SQL pain points, such as the excellent folks at CockroachDB, and the various folks building replication layers on top of Postgres, can hopefully keep the market for database startups alive long enough for someone else to fix the NoSQL landscape as well.

[0] https://aphyr.com/posts/284-call-me-maybe-mongodb , where one finds that Mongo actually isn't guaranteed consistent during partitions, actually did hit us in production, and we had to dig through a rollback file manually (shudder); fun times. On the other hand, see: https://aphyr.com/posts/330-jepsen-rethinkdb-2-2-3-reconfigu...

Post reply on HN