Cassandra and The Enterprise Tension

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

Apache Cassandra Logo

It was really just a matter of time until someone began offering commercial support for Cassandra, so it was with no surprise that I read that Jonathan Ellis and co had spun out of Rackspace and up Riptano. Given the market opportunities in front of NoSQL generally (coverage), and the interest in Cassandra specifically, this was not just logical but inevitable. What I am fascinated to watch with Riptano, however, as with many of the other commercialized or soon-to-be NoSQL stores is how they manage the enterprise vs web tension.

It’s no secret that web native firms and traditional enterprises are different entitities with differing workloads. There is overlap, to be sure, but if the needs of enterprises were aligned with web native firms, we probably wouldn’t have projects like Cassandra in the first place: the relational databases would have long since been adapted to the challenges of multi-node, partitioned systems demanding schema flexibility. But they weren’t, and so we do.

As we’ve documented here before, there is perhaps no bigger embodiment of this tension than MySQL. Originally the default choice of firms built on the web, it gravitated further towards the more traditional enterprise relational database market over the years in search of revenues. In went features such as stored procedures and triggers, and up went the complexity of the codebase. By virtually any metric, the MySQL approach was wildly succcessful. It remains the most popular database on the planet, but it was versatile enough in web and enterprise markets to command a billion dollar valuation.

It is virtually certain that Riptano and every other NoSQL store will, at some point, face a similar fork in the road. Priortize web workloads and features, or cater to the needs of enterprises who will be looking for things that users like Facebook and Twitter not only might not benefit from, but actively might not want. While the stated intention of Ellis is to not fork Cassandra, then, I’m curious as to whether or not there will come a time when it will become necessary.

Enterprise users, at some point, will undoubtedly want something added to Cassandra that makes it less attractive to, say, Facebook. At which point there Riptano has a choice: add it – they’ll have commit rights, obviously – and trust that the fallout from the unwanted (by one group) feature will be minimal, decline to add it, or maintain a fork. With the latter less logistically expensive these days, perhaps that will become more viable an approach – even in commercial distributions – over time. Assuming the feature is added, Facebook, Twitter et al then have a similar choice: use the project, evolving in a direction inconvenient to them though it may be, fork it, or replace it.

Either way, it will be interesting to watch the developmental tensions play out. Kind of makes you curious as to what Drizzle versions of Cassandra might look like.


  1. This is a very good point, and why we built Drawn to Scale — we focus on commercial/enterprise first, because they don’t need just a database. We’ve found these types of customers need a database ecosystem.

    There’s a ton of companies our there who are data-centric, but don’t want to hire distributed computing experts to handle their data volumes 🙂

  2. […] of more liberal alternatives. The default licensing choice, in fact, appears to be Apache 2.0 (e.g. Cassandra, Scribe, Tornado and Thrift), with other licenses employed tactically for compliance or […]

Leave a Reply

Your email address will not be published. Required fields are marked *