Hacker News Reader

Comment by astral303 | Hacker News Reader

Cache getting out of control and the server getting OOM killed needs to be fixed before I'd consider the database production-ready for large sets of data.

https://github.com/rethinkdb/rethinkdb/issues/97

It's a little disappointing that it has not been resolved for several releases now.

Is there a target milestone for a production-ready release of RethinkDB? Is it 1.8 or 1.9?

View on HN

You are absolutely right. FYI, the rationale for this decision is that people are rapidly adopting Rethink and writing applications on top of it, so we decided to allocate most development resources to nailing down ReQL as quickly as possible so people won't have to rewrite their apps. Some operations issues (like #97) unfortunately had to temporarily take a backseat. I suspect we'll be able to resolve #97 in the 1.8 release.

RethinkDB will be marked production ready when it hits 2.0, though it will be ready for useful work way before that. (A huge number of people are already using it in their daily work and building important software on top of Rethink)

That's a reasonable rationale. Thanks!

I've generally found the Rethink guys very level-headed and customer-focused. I made a feature request a year or so ago for a feature that was pretty outside the scope of a DBMS (custom memory/CPU limits for map/reduce operations) and they implemented it in a day or so, even though I was just asking if it's possible in theory.

They even sent me a small care package with a hand-written note, it was great of them. Marc, the guy who sent me the package, is now one of my regular DOTA2 teammates, and he's great at that too.

Major props to them, I really hope Rethink becomes as amazing as I think it will. I'll give it another spin over the weekend and write it up.

Congrats on the new release, guys!

The most inconspicuous sign of RethinkDB taking over the world is what they named this release: Nights of Cabiria. It shows they have the strength to laugh at themselves, at how hard it is to build something like this, and how people have treated them so far.

I'd encourage you to learn more about that movie.

https://en.wikipedia.org/wiki/Nights_of_Cabiria

These are interesting parallels and I suppose much of this might be true subconsciously, but it wasn't premeditated. For each release we just have a random person on our team pick a classic movie. @mglukhovsky picked this one; I don't think he thought it through that far, though :)

Is there a target milestone for a production-ready release of RethinkDB? Is it 1.8 or 1.9?

1.0 is supposed to mean production-ready. Are you suggesting this should be a 0.7 release?

Under semver (which isn't the only versioning scheme, but certainly among the more common of the ones that have a firm definition of what 1.0 means), it means "stable API", which doesn't necessarily mean "production ready".

Version numbers don't have on single universally accepted set of defined semantics.

If I remember correctly, the RethinkDB team opted to match their in-house version numbers with public releases. So the 1.x releases would be more comparable to 0.x releases for other projects, and 2.0 would be considered stable and production ready.

slava @ rethink -- this is exactly right. Sorry for confusion.

This is similar to node.js versioning, I think.

Reply on news.ycombinator.com