DataStaxのCTOで、Apache Cassandraのプロジェクト議長であるJohnathan Ellis氏は Cassandra SF 2011で基調講演を行った。昨年の主なプロジェクト成果は、複数データセンターへのデプロイのサポートにおける改善、最適化された読み込みパフォーマンス、統合されたキャッシング、SQLに似た言語の CQL を含んだクライアントAPIの改善などである。 Cassandra 1.0のフィーチャフリーズは２０１１年の１０月の予定で、効率的なデータベース修復、ストレージの圧縮、最適化されたパフォーマンス、拡張されたCQL言語の全てに磨きをかけることである、と強調していた。
- log structuredストレージを使用しており、メモリーにバッファして、次にランダム ライトでなく、ストリーミング ライトする
- 並列エンジンを持っている：テーブルや行のロックはなく、アップデートは比較とスワップで実装されている－マテリアライズド・ビュー用の大きな行をサポートするためにこれが必要である
- イベンチュアル・コンシステンシー あるいは完全な一貫性のために調整でき、ローカルノードに quorumがある場合、成功するオプションを含む
Cassandra 0.7は2011年の1月にリリースされ、以下の機能を含んでいる。
- マニュアルでノードを再スタートしなくてもColumn Family を作成できる機能
- 古いデータを自動的に削除できるようにカラムを期限切れにする
- 2次インデックスが組込まれた（InfoQが 報告したように、カンファレンスでインデックス化について Ed Anuff氏がプレゼンした制限についても参照）
Cassandra 0.8は2011年6月にリリースされ、以下のようなフィーチャがある。
- CQL - 単純化したSQL変形版、クライアント アプリケーションにより高レベルなインターフェースを提供する
- Counters - 自動的にカラムを増加させる機能
- memtable用のメモリーを自動的に調節する：Ellis氏によると、以前のバージョンでは、メモリーを過剰に割り当ててJVMがクラッシュしてしまうことがよくあったが、何百、何千のColumn Family を持てるようになった
- バルクロード インターフェース
その後の技術者トークで、CQLの作成者である Rackspaceの Eric Evans氏は、CQLではネストしたクエリやジョインのようなもっと高度なSQLイディオムを恐らくサポートしないことを認めた。理由は、 Cassandraはそれらを効率的にサポートできないからだ、という。 Cassandraがコプロセッサをサポートしたら（minやsumのような）アグリゲータをサポートするだろう、と言った。
- CQL 1.1：複合カラムとPrepared Statement のサポートを追加する
- 圧縮：非常に変化する行サイズがあるので、 Cassandra. 1.0では圧縮はずっと難しいが、ブロックあたりの行と行あたりのブロックの両方を圧縮するのをサポートする。
- コンパクション：Cassandra はGoogleの leveldb のアプローチを一般化して、あるキーにデータが持てるレベル当たりせいぜい 1 SSTable持つことになるので、その結果最悪のマージの場合、現在の最悪値がnならlog(n)SSTableとなる。ここで１ column familyを表すのに使われるのが n SSTableである。
- Repairの最適化：現行の実装では余分なデータを送信し、保存しているのでおそらくディスクを浪費している。1.0では、これが最適化される。
- リードの最適化：SSTableは最大の（クライアント提供の）タイムスタンプによってソートされ、リクエストされたカラムの最新値が見つかったところで、マージの早期終了ができるようになる。
1.0のあとは、Ellis氏はCassandraを開発者がもっと使いやすいものにすることに焦点を当てる、と言う。 Brisk (以前InfoQが書いた）によって、ETL無しでリアルタイムなデータを分析できるようになる、とも言った。SolandraはCassandra上に作られたクラスタされた Solr である、とも言った。Ellis氏は、これらはCassandra上に作られたより広大なデータのトレンドを示す最初の2つの例である、と言った。彼は将来もっとこの傾向を見ることを期待している。