Cassandra handles heavy write traffic across data centers, but only when tables are modeled around queries and the cluster is repaired and compacted on schedule. Agnotic Technologies designs, tunes and operates Apache Cassandra clusters with your team, from the first table to version upgrades.
Trusted by global innovators
Cassandra consulting
Apache Cassandra consulting is designing the tables, replication and operations of a Cassandra cluster so reads stay fast and data stays correct as it grows. Agnotic Technologies models one table per query, sizes partitions, sets consistency per data center, picks compaction per table, schedules repair and plans version upgrades.
We work on new clusters and on existing ones with slow reads, growing disks or deleted data that came back.
Cassandra is a wide-column database built for high write volume across many nodes and regions. When a workload needs joins, ad hoc reporting or transactions across many rows, we say so early and suggest a better fit.
Data modeling
Cassandra has no joins, so the model starts from the application's queries, not from its entities.
Each screen and API call the application needs, with its filters, sort order and expected volume. This list is the design input.
Data is duplicated across tables on purpose, so every query reads one partition. Writes go to each table that needs the data, often in a logged batch.
The partition key decides which nodes hold the data. It must spread writes across the cluster and match the query's equality filter.
Clustering columns sort rows inside a partition, so a range query such as the latest readings for a device returns in order with no sorting at read time.
Time series and event tables add a time bucket, such as a day or a month, to the partition key so no partition grows without limit.
We estimate rows and cells per partition with the formula in the Cassandra documentation, then test with your largest customers or devices.
Failure points
The failures we look for first when we review a cluster, each with the check that finds it.
Challenge
Oversized or hot partitions: one customer, device or day holds far more data than the rest, and the nodes that own it slow down.
Agnotic approach
Check nodetool tablehistograms and the large partition warnings in the logs, then add a bucket to the partition key or split the hot key.
Challenge
Tombstones pile up from deletes, null writes and expired TTLs, so reads scan many dead cells.
Agnotic approach
Check tombstone warnings in the logs and tombstones per slice in nodetool tablestats. Stop writing nulls, use time-window compaction for TTL data and avoid row deletes inside wide partitions.
Challenge
Repairs missed for longer than gc_grace_seconds, so deleted data reappears from a node that missed the delete.
Agnotic approach
Check the last successful repair per table against its gc_grace_seconds, and schedule repairs well inside that window.
Challenge
The wrong compaction strategy for time series, so expired data is never dropped and disks keep growing.
Agnotic approach
Check the compaction strategy and SSTable count per table, and move time-ordered TTL data to time-window compaction or a tuned unified setting.
Challenge
ALLOW FILTERING and secondary indexes used for everyday queries, so reads touch every node.
Agnotic approach
Check query logs for ALLOW FILTERING and index use, then add a table for the query, or use storage-attached indexes where the filter suits them.
Challenge
Consistency levels that do not overlap across data centers, such as writes at LOCAL_ONE and reads at LOCAL_QUORUM that expect to see them.
Agnotic approach
Check the consistency level each driver call sets, and pair reads and writes so their replicas overlap, usually LOCAL_QUORUM for both.
Compaction
Compaction is set per table. The right choice depends on how the table is written, read and deleted.
| Code | Name | Typical use |
|---|---|---|
| UCS | Unified Compaction Strategy | Recommended in the Cassandra 5.0 documentation for most workloads. It can be configured to behave like the older strategies and can change parameters without a full recompaction. |
| STCS | Size-Tiered Compaction Strategy | Write-heavy tables with few range reads. Needs spare disk space while large compactions run. |
| LCS | Leveled Compaction Strategy | Read-heavy tables with frequent updates, where each read should touch few SSTables. Costs more disk I/O on writes. |
| TWCS | Time Window Compaction Strategy | Mostly immutable time series written in time order with a TTL, so whole SSTables expire and are dropped together. |
Consistency
Consistency is chosen per request. We set it per query from how fresh the answer must be and how far the request may travel.
Example: Reads and writes for users served from one region
Approach: A majority of replicas in the local data center must respond. Used on both reads and writes, a client sees its own writes without waiting on other regions.
Example: Writes that must reach every region before they count
Approach: A majority in every data center must respond, so latency follows the slowest region. We keep it for the few writes that need it.
Example: Clusters in a single data center
Approach: A majority of all replicas. Across regions it adds cross-region round trips, so multi-region clusters usually use LOCAL_QUORUM instead.
Example: Metrics, logs or caches where a slightly stale read is acceptable
Approach: One replica responds, for the lowest latency. Repair and read repair close the gap later.
Hosting
Both can work. The choice depends on control, team skills and which Cassandra features your application uses.
We confirm which release lines are still maintained and read the upgrade notes for every version between yours and the target.
PlanA test cluster restored from a snapshot runs the new version against your real queries and drivers.
TestNodes are upgraded one at a time with repairs paused, and the cluster keeps serving traffic throughout.
UpgradeOnce every node runs the new version, SSTables are rewritten to the new format, and features such as storage-attached indexes are trialled on chosen tables.
AdoptFit check
Cassandra is a poor fit for some workloads. These signs point elsewhere.
High write rates keyed by device and time, read back as recent ranges.
Per-user timelines and message history written constantly and read by user.
Data replicated to several data centers, so each region reads and writes locally.
Large, mostly append-only records looked up by customer or account.
Fraud signals, personalization profiles and counters read by key at low latency.
Scope and cost
We do not publish prices. These factors decide big data Cassandra cost, and we size them on the scoping call.
A new model is a query list and a schema. An existing cluster adds a review of logs, metrics and repair history.
Each query usually becomes a table, with its own writes and tests.
Each data center adds replication settings, consistency choices and failure tests.
Moving data into new tables or from another database means a backfill and a switch-over the application controls.
Upgrading across several release lines adds test cycles.
Runbooks for repair, backups, node replacement and on-call.
References
Limits and rules from the Apache Cassandra documentation that shape our tables, consistency choices and repair schedules.
The Apache Cassandra data modeling guide takes a query-first approach: it lists the queries the application's screens and use cases need before any table is designed.
Source: Apache Cassandra 5.0 documentation: defining application queriesCassandra's hard limit is 2 billion cells per partition, and its documentation warns that performance problems are likely well before a partition reaches that limit.
Source: Apache Cassandra 5.0 documentation: evaluating and refining data modelsLOCAL_QUORUM requires a majority of replicas in the coordinator's data center to respond, and the Cassandra documentation notes it guarantees that reads see the latest write made within the same data center.
Source: Apache Cassandra 5.0 documentation: Dynamo architecture and consistency levelsThe Cassandra documentation says repair must run often enough that the gc grace period never expires on unrepaired data, or deleted data can reappear; with the default 10 day grace period it suggests repairing every node at least once every 7 days.
Source: Apache Cassandra 5.0 documentation: repairOn 21 October 2026 the Apache Cassandra download page listed 5.0 as the latest GA version, maintained until the 8.0 release, with 4.1 maintained until 7.0 and 4.0 until 6.0.
Source: Apache Cassandra downloads
