Cassandra 2.0 was released in early September this year and came with some interesting new features, including “lightweight transactions” and triggers.


Despite the rising interest in the various non-relational databases in recent years, there are still numerous use-cases for which a relational database system is a better choice. The latest major release of Cassandra (version 2.0) provides some interesting features that aim to close this gap, and offers its fast and distributed storage engine enhanced with new options that will make users’ lives easier.

Lightweight transactions (compare-and-set)

One of the more interesting of these improvements is the introduction of optimistic lock-style “lightweight transactions” or “compare-and-set” DML operations to CQL.

INSERT INTO USERS(userid, first_name, last_name)
VALUES ('OpenCredo', 'Open', 'Credo') 

The CQL language has been extended with the IF clause for INSERT and UPDATE commands, which lets the user invoke a data modification operation pending some condition specified in the IF part, and have a guaranteed isolation for the test and the modification: no other process can change the values while such a compare-and-set command runs.

The addition of lightweight transactions enables use cases that simply weren’t possible to implement safely in prior releases. This is achieved without compromising Cassandra’s ability to scale, as would be the case if traditional RDBMS-style transactions relying on locking were used.

Pro Con
  • Increased featured parity with relational databases
  • No need for any external service, tool or synchronization mechanism
  • Retains its good scalability characteristics
  • Does not offer true ACID transactions
  • First release included major bugs, which may now be fixed
  • Operations become slower


The other item in the feature-list of Cassandra 2.0 that caught our attention is triggers.

Triggers have been around for many years in relational database systems, and they have some controversial properties in general. Up until this release Cassandra has offered no option for those requiring triggers; the addition of triggers allows for greater flexibility.

It’s still very much an experimental feature (the API is scheduled to change), and definitely not recommended for production usage. Still, it’s interesting to take a glance into the future and see what you can achieve with them.

Pro Con
  • Shows potential
  • Can execute anything in the server JVM
  • Depends on Cassandra-internal classes
  • Written in Java, without access to CQL types
  • Can’t (easily) read the database
  • You have to deploy jar files on all the nodes of your cluster


In future blog posts we will look at both lightweight transactions and triggers in more detail, including a code-level exploration of API.

Whilst not yet mature, these features mark a clear desire to bring Cassandra closer to the functionality of traditional relational databases.

The following two tabs change content below.

David Borsos

In recent years David has been working in the financial industry, developing web-based enterprise applications, mostly of internally used tools that supported the maintenance and operations of a large IT infrastructure. He is focusing on server-side development with Java and Spring, interested in NoSQL technologies and the Scala programming language. For several years, David was helping to organize the Challenge24 programming contest held every year in Budapest, Hungary. David enjoys contributing at speaker events, which includes Cassandra Summit Europe 2014.

Leave a Reply