4 ms·
RethinkDB really managed to build quite a lot of positive feelings in me on the back of not very much technology. But what technology was there seemed very robu
by fusiongyro 10y ago
RethinkDB really managed to build quite a lot of positive feelings in me on the back of not very much technology. But what technology was there seemed very robust. Just kind of incomplete.
My situation was very similar to latch's above. I vetted it earlier this year, after having developed warm fuzzy feelings for it last year at another company. We wound up going with Postgres + Solr because A) we've used them before, B) they performed a lot better than Rethink, and C) Rethink's compensating features (distribution) weren't worth the tradeoff.
I thought Rethink seemed like Mongo done right. Both have a simple document storage model. Rethink embraced "relations" a lot better, and seemed interested in borrowing some good ideas from relational theory. Having a uniform query language was a good idea; the "builder" style was an odd choice but whatever. Where Mongo ignored and failed to address Aphyr's concerns directly (and antirez seemed to emit a cloud of interminable semantics debates) Rethink actually reached out to Aphyr for testing and rapidly took action based on his recommendations. They accepted the criticism readily and went to some effort to be transparent about what they could and could not do. Failover was not a 1.0 feature, so they didn't hose it totally. The admin interface was beautiful. You really felt like you had a simple, powerful tool that you could understand.
Performance wasn't great. This was the showstopper for me. But to be honest, I probably wasn't going to give them a dollar even if it was a lot better. I'm not paying for Postgres or Solr either. I don't know how you bootstrap a database business. The Mongo/MySQL approach of "make garbage, monetize, hope someday you can refactor it into shape" looks obviously wrong stacked up against Postgres, which always took the academic approach of "first make it right, then make it perform." But performance is a feature and it takes a long time to make a database right, let alone perform. I think they took the right approach. It's just a long process, and it may not be compatible with startup culture.
- tkyjonathan 10y agoMongo may have been to ship non-acid compliant garbage, but MySQL just shipped with less features than Postgres.
- fusiongyro 10y agoI don't agree. To take a microscopic view of just one of them, consider TIMESTAMP. It was identical to DATETIME, except that if you touch that row, the _first_ TIMESTAMP column gets automagically updated to the current time. This isn't the kind of thing that happens by accident, someone decided that this was desirable and went out of their way to write code to make it happen. The feature caused a great deal of confusion and probably a significant amount of data loss. It's more than merely non-standard or in some sense "less" than Postgres, it's actually inimical to the model of what's going on, in several senses: column "ordering," a data type with behavior. This kind of "here's a bucket of special-cases" sloppiness is thematic for both MySQL and Mongo.
- Jweb_Guru 10y agoOh, come on, MyISAM didn't even support transactions.