Cassandra data modeling feels strange if you come from relational databases. The big shift is this: you model around queries first, not around perfect normalization.
This post is part of the DBApreneur starter series. The goal is to explain the topic in plain language, then give you practical checks or examples you can use in real work.
Query-first design
Before creating tables, write down the exact queries the application needs. Cassandra is excellent when queries match the table design. It is frustrating when you try to query it like a relational database.
Denormalization is normal
In Cassandra, duplicating data across tables is common. You may store the same business fact in multiple query-specific tables. The tradeoff is more write complexity for faster reads.
Partition size
Partitions should not become too large or too hot. A partition that receives too much traffic can become a bottleneck even if the cluster has many nodes.
Example mindset
Instead of asking "What is the perfect customer schema?" ask "How will we read customer orders, by which key, in what order, and at what volume?"
Practical checklist
- Start with the problem you are trying to solve.
- Confirm the environment and version before applying any command.
- Test in a lab or lower environment first.
- Keep notes of what changed and why.
- Review performance, security, and rollback impact before production.
Final thought
Good engineering is rarely about memorizing commands. It is about understanding the shape of the system, asking better questions, and making changes that are boring in production. That is the kind of DBA work this series is trying to encourage.