Apache Cassandra

AddisDB connects to Cassandra over its native CQL protocol on port 9042. Keyspaces and tables come from system_schema, and partition and clustering keys are surfaced as the table’s primary key, so the sidebar tells you how a table is actually laid out.

Who it is for

Cassandra is a wide-column store built for write-heavy workloads at scale with no single point of failure. Every node is equal, replication spans data centres, and adding capacity means adding machines.

A write is an append to a commit log and an in-memory table, never a read-modify-write — which is why sustained write throughput stays flat as data grows, and also why deletes are tombstones that cost you on read until compaction removes them.

The trade is that you model tables per query rather than normalizing. There are no joins, and a predicate on a non-key column is refused unless you add ALLOW FILTERING — which is Cassandra telling you the query would read the whole ring.

It suits time-stamped event and sensor data, messaging and activity feeds, and any system where sustained write throughput and multi-region availability matter more than ad-hoc query flexibility.

Set up the cluster

1. Local: docker run -p 9042:9042 -d cassandra, then give it a minute — the first boot is slow.
2. Managed: DataStax Astra, Amazon Keyspaces or Instaclustr. Copy the host and credentials from the console.
3. Create a keyspace with a replication strategy before you create tables.
4. The default superuser on a fresh cluster is cassandra / cassandra — change it before anything reaches production.
5. For real deployments use NetworkTopologyStrategy with a replication factor per data centre; SimpleStrategy is for a single-node laptop and nothing else.

CREATE KEYSPACE app WITH replication =
  {'class': 'SimpleStrategy', 'replication_factor': 1};

Connect from AddisDB

1. New Connection → Cassandra under Wide-column. Port prefills to 9042 and the username to cassandra.
2. Enter the host and credentials, and set Keyspace to the keyspace you want as your default.
3. Test, then Save.

Reading a table definition

The primary key clause is the whole story of a Cassandra table. The first element — or the parenthesized group — is the partition key, deciding which node holds the row; everything after it is a clustering key, deciding the sort order inside that partition. AddisDB shows both, which is what lets you tell at a glance whether a query you want to run is possible.

CREATE TABLE readings (
  sensor_id uuid,
  bucket    date,
  ts        timestamp,
  value     double,
  PRIMARY KEY ((sensor_id, bucket), ts)
) WITH CLUSTERING ORDER BY (ts DESC);

That bucket column is the standard fix for an unbounded time series: without it, one sensor’s entire history lands in a single partition and grows forever.

What AddisDB gives you

• Keyspaces and tables in the sidebar with real column types, partition keys and clustering keys — system keyspaces hidden so the list stays useful.
• CQL results decoded to the grid, with the JSON tab for nested collections and UDTs.
• Read-only enforcement — anything that is not SELECT, USE, DESCRIBE or LIST is blocked.
• The Chart view, ⌘K search across every connected database, and AI chat grounded in your real schema.
• Per-table size estimates and the connected-clients view in the Live Monitor.