Cassandra, PostgreSQL or MongoDB: when to reach for a wide-column NoSQL

← Back to the section

"Let's use Cassandra, it scales" is a sentence that often hides no real understanding of how Cassandra differs from a normal database and what its scale costs. Cassandra solves a very specific class of problems and makes everything else worse. Let's see what it is and compare it with two other popular options — relational PostgreSQL and document MongoDB (their head-to-head is a separate article). This article is about the choice; a detailed breakdown of how Cassandra works is in a dedicated section.

What Cassandra is

Apache Cassandra is a wide-column distributed NoSQL database. It grew out of two ideas: its data model comes from Google Bigtable, and its way of distributing data across nodes from Amazon Dynamo. Hence two defining traits:

• A "wide row" data model. Data lives in tables with a query language (CQL), but is arranged differently than in a relational database: a partition key holds a group of rows, grouped and ordered by clustering columns. One partition can hold anywhere from one to millions of ordered rows — that's what "wide-column" means. You design such tables not "from entities" but from queries.
• No master node (masterless). In a Cassandra cluster all nodes are equal — there is no leader that all writes go through. Data is spread across a ring by the hash of the partition key, and every node accepts both reads and writes. This is what gives Cassandra its main property.

That property is linear horizontal write scalability. Add nodes and throughput grows proportionally, with no single point that the load piles up against. Add to that built-in active-active replication across multiple data centers: the cluster keeps accepting writes even if a whole data center goes down.

Cassandra vs PostgreSQL

PostgreSQL is a relational database with a single primary node for writes. Its strengths are a strict schema, JOIN across tables, ad-hoc queries, and ACID transactions: a money transfer between accounts either goes through completely or not at all.

Cassandra is the exact opposite where that's needed for scale:

• No JOIN and no ad-hoc queries. A query must hit the partition key; "now show me from a different angle" won't work without a table designed for that angle in advance.
• No full cross-row transactions. There are lightweight conditional operations, but you cannot move money between accounts the way PostgreSQL does.
• Consistency is tunable per query. Cassandra isn't "always inconsistent": the consistency level is set separately for reads and writes. Read and write with a single replica — fast, but a read may briefly lag (eventual consistency). Read and write with a quorum — you get strong reads (the R + W > RF rule), at higher latency. It's a deliberate choice of the speed-versus-freshness balance, not a hard sacrifice of consistency.

Bottom line: take PostgreSQL when transactions, relationships, and flexible queries matter on data that fits on one powerful server (plus read replicas). Take Cassandra when write volume and the "always available" requirement outgrow what a single primary node can carry.

Cassandra vs MongoDB

MongoDB is a document database: data is stored as JSON-like documents with a flexible schema. Both are NoSQL and both can scale by sharding, but their nature differs:

• Topology. MongoDB has a primary node per shard (a replica set with automatic failover). Cassandra has no primary at all — any node takes a write. For "active writes in several regions at once," Cassandra is the more natural fit.
• Queries and indexes. MongoDB is richer: secondary indexes, flexible field queries, aggregations, multi-document transactions. Cassandra is stricter — everything revolves around the partition key.
• Niche. MongoDB is a general-purpose database for a changing domain and varied queries. Cassandra is a narrow tool for a huge write stream and constant availability.

Simplified: MongoDB is more flexible in model and queries; Cassandra is stronger in write scale and multi-region availability.

Data model: queries first, tables second

The classic beginner mistake with Cassandra is to design tables the relational way, "by entities," and then be surprised the query you need is impossible. In Cassandra you design from the queries: first you write down exactly which reads production will do, and build a dedicated table for each, deliberately duplicating data (denormalization is the norm, not a sin). The partition key decides which node holds the data and by which key it can be fetched; clustering columns set the order within a partition.

Hence a practical rule: if you don't know up front how the data will be queried, or the queries are varied and changing, Cassandra is contraindicated. It rewards predictable key lookups and punishes ad-hoc analytics.

Comparison

When to choose what

• PostgreSQL — the default: relations, transactions, flexible queries, data on one server. Most services are fine with it for a long time.
• MongoDB — a changing domain, a document model, varied queries; you need horizontal growth but not an extreme write stream.
• Cassandra — telemetry and IoT events, activity feeds, logs, counters, messages: a huge write stream, predictable key lookups, an "always available" requirement, and writes in several regions at once.

Common mistakes

• Reaching for Cassandra "for scale" without a write stream. For a single-server service this just trades away transactions, JOIN, and flexible queries for scale you don't need.
• Designing Cassandra tables the relational way. Without designing from the queries, the reads you need become impossible or expensive.
• Expecting transactions and analytics from Cassandra. Money transfers and ad-hoc reports aren't its job; keep PostgreSQL alongside for that.
• Confusing "NoSQL" with "modern." MongoDB and Cassandra are different tools for different jobs, not a trendier relational database.

In short

• Cassandra is a wide-column distributed NoSQL with no master node; its forte is linear write scalability and constant availability, including across multiple data centers.
• Unlike PostgreSQL, it has no full transactions, JOIN, or ad-hoc queries; consistency is eventual by default.
• Unlike MongoDB, it has no primary node and is stronger at write throughput, but stricter in model and queries.
• Cassandra tables are designed from the queries, deliberately duplicating data.
• Its niche is narrow: telemetry, events, logs, counters — a large write stream and predictable key lookups. For relations, transactions, and analytics, use PostgreSQL.