Cassandra isn't designed to replace relational databases for all use cases. There are certain use cases where Cassandra excels, certain use cases where an RDBMS excels, and plenty of ground in between where you're making tradeoffs.

CQL was designed to resemble SQL in order to present an API that is reasonably familiar for most developers. It's quite limited when compared to SQL because it focuses on the areas where Cassandra excels.

(Disclosure: I'm a Cassandra committer.)

What was very interesting was bullshitting with somebody who knew a good chunk from DataStax, and realizing that the use cases for Cassandra actually do edge out pretty far into traditional business territory. It's something that you could actually envision replacing mainframes and whatnot in many cases, even for relatively mundane line-of-business applications.

I think they can do it, but I dont think the ROI would cover the investment to change hardware and software for a system that currently works. Unless you are up against an hard EOL for your 'traditional' install I think it would be a large gamble to change. Im speaking for 'traditional' enterprisey install bases only though.

This is true. Most companies either start using Cassandra when their existing database infrastructure is struggling with a particular workload or they're planning a new feature that would be prohibitively difficult or expensive with an RDBMS.

The one exception to this might be a need for higher availability, especially if expanding to multiple datacenters is part of the plan.

Can you elaborate on some specific use cases?

Why are update statements actually inserts? Am I missing something ( besides eventually consistency by design ) or are they trying to trick me?

Because they don't do a read before insert/update/delete, so random inserts don't do random reads/io, but create new versions.

They aren't trying to trick you. Bigtable,hypertable,hbase (i think even tokudb/mx) work the same.

From the article:

> Most new applications now run on the Web, across data centers and geographies, so that data can be close to the users wherever they are. That’s what DataStax is designed to support, Mr. Murphy said.

I think to do that with Oracle is extremely expensive, so that would be a nice sweet spot to steal customers from Oracle if the workload matches what Cassandra can deliver (not all workloads, though, mind you)

If you read the way tutorials pitch CQL, you will assume it's replacing SQL. But once you understand how it works, no it's not replacing SQL.

Edit: We actually use Cassandra and have found it to be an outstanding solution for our use case. But I feel like CQL's superficial similarity to SQL leads many to confusion until you dig into how it works.

The fact there is an UPDATE statement that is actually an INSERT is clever, but possibly misleading to many users. The design is for insert only so you hate to see syntax that is actually a different semantic.

It's because i've read them, and I know they suck(feature-wise). It's like mongodb all over again (replace your rdbms).

I honestly don't recall seeing much, if any, evangelism to the extremes of "hey you don't need a relational database anymore" as it relates to Cassandra. Talks I've seen have generally focused on using it as a tool to fit a specific niche/do something that the existing RDBMS wasn't optimal for.

Disclosure: C* User

About the talks, yeah. There is no one talking about how we replaced our rdbms (except where they were using the rdbms as kv or something similar like reddit), because it isn't possible.