Hacker News Reader

Comment by misterbowfinger | Hacker News Reader

Wow. I was seriously rooting for them. I'm looking forward to Slava's posts about their challenges on the business side. There's a part of me that's angry that MongoDB - which some would say has made an objectively worse product - has succeeded.

My initial thought is that MongoDB has done a way, way better job at SEO. The number of blog posts about RethinkDB pales in comparison to Mongo. I wonder if they got beat on sales as well? Not sure.

View on HN

Mongo also got there "first". I mean, Mongo isn't much compared to Rethink, but they're both in the "not a traditional SQL database" camp and Mongo came before and had all the hype first.

I wouldn't be surprised if people a) didn't use Rethink because they're happy with Mongo and its popularity b) hated Mongo and saw Rethink as too similar/didn't research it enough.

Well, Couch DB got there first but it didn't help them much. I think you're right it was mostly about social media marketing.

I think couch never caught on because of it's very different querying paradigm that was enough of a friction to mass adoption.(which has only been fixed by making a mongo like DSL in the 2.0 release).

Early couch had scaling problems. We built a product around it and had a terrible time keeping it running at scale. Ruined erlang for me, too. Not from the language, but the problems with the build tools.

I'm not sure if anyone else ran into this, but I evaluated RethinkDB for three separate projects over the years, and there was always that one missing feature. I don't remember exactly what they were, but I think the first time it was secondary indexes, the second was full text search and the third was geo indexes.

Went with Postgres for all three.

When Windows Phone 7 came out, without background tasks, MS was quick to point out that the iPhone didn't originally have it either. It was a silly argument; Neither Apple nor Google were selling phones without that feature at that time.

I'm not saying Rethink did anything wrong. And by bringing up MS, I don't want anyone to think Rethink had the same sense of entitlement as Microsoft.

Your v1 has to compete against your competitors current version, not their 5-year old v1. RethinkDB had a lot of powerful features, but it also lacked a lot of features that for me, and I have to suspect many others, made it an impossible choice.

(Also, I hated the query syntax. I was willing to fight through it, but I often wondered if that was turning people off)

I'm genuinely surprised at the number of people who vetted RethinkDB and are now really concerned with this news. With the number of solutions out there to accomplish the same or more RethinkDB almost seems like a novelty choice. Surely the decision to make it business critical came with the understanding and acceptance that the company might go bust? I'm not sure what was accomplishable with RethinkDB that wasn't with any number of other alternatives or combinations of alternatives.

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.

Mongo may have been to ship non-acid compliant garbage, but MySQL just shipped with less features than Postgres.

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

Oh, come on, MyISAM didn't even support transactions.

Here is a blog post mentioning the service offerings around MongoDB as another factor: http://blog.dripstat.com/mongodb-vs-rethinkdb-why-we-had-to-...

(via this HN submission: https://news.ycombinator.com/item?id=12650033)

My sense is that the market for NoSQL databases is large enough that RethinkDB could have focused on a particular customer segment and grown from there. So even if Mongo was the dominant player in NoSQL land, it seems at least possible that Rethink could stick it out and win.

Perhaps this is what RethinkDB's strategy was all along with targeting real-time applications. I wonder if they were just... too early?

Still, the market for companies willing to pay for databases in NoSQL is absolutely tiny. If those NoSQL products want to grab a share of the SQL world which does have money, they are competing with very serious vendors. So the market is consolidating. Its just the way it goes.

MongoDB has received a huge amount of venture funding: $311M vs $12.2M for RethinkDB. That makes a big difference how far you can grow as a business if you use the money even half-way rationally.

Given that the market for document DBMS is pretty small to begin with it's tough to beat a 25x difference in budget unless you have a product that is a complete game-changer. It will be interesting to see Slava's analysis. Meanwhile I wish the team and RethinkDB users well. DBMS start-ups are damn tough to pull off.

I originally thought funding would play a big role, but the early, 2-3 year period of funding for both is comparable:

RethinkDB, 2009-11 = $4.2MM

MongoDB, 2008-2009 = $4.9MM

It's true that MongoDB quickly closed on a $6.5MM Series C in Dec of 2010, one year after their Series B. For Rethink, it took them another 2 years to get the last $8MM. There's no question that MongoDB was "better" at raising more money, faster.

I'm just thinking out loud here, but I wonder if MongoDB made a conscious tradeoff to sacrifice good tech to have better marketing & sales early on.

Crunchbase links here:

- https://www.crunchbase.com/organization/mongodb-inc/funding-...

- https://www.crunchbase.com/organization/rethinkdb/funding-ro...

No, still diff league: if 50% went to dev, 10 devs << 20. For example, 1-2 parallel teams could focus purely on monetization: managed hosting, weird enterprise features, sales engineering, etc. Compounding returns on that turn into more funding, and history unfolds.

Exactly. It's sad that a technical superior product can't make it while something like Mongo can.

Reply on news.ycombinator.com