A Kotlin ORM that doesn't pretend Cassandra is SQL with extra steps.

Cassandra has no joins and no foreign keys. Any “find X by Y” query that isn't servable by partition key needs a hand-maintained denormalized table — and a save() that updates the primary table but forgets (or half-fails) the lookup table leaves a user invisible by email, with nothing in the code that looks wrong.

@LookupIndex makes it an annotation, written atomically with the primary row, not a discipline you have to remember in every write path.

Relational muscle memory for “delete by ID” doesn't account for clustering keys. DELETE WHERE partition_key = ? on a clustering-keyed table deletes every row in that partition, not the one row you meant — a real data-loss bug, caught the hard way in Kandra's own ISS-025.

deleteById/findById take the full primary key as arguments. Call one with fewer values than the key requires and it fails at call time with KandraSchemaException, naming the missing column — not a silent partition wipe.

Cassandra's LOGGED BATCH is the only cross-table atomicity primitive, and it's easy to write code that looks transactional (a few save() calls in a row) while it actually runs as N independent, non-atomic writes.

KandraBatchScope exists specifically for this — and its methods are named saveInBatch, not save, a direct scar from almost shipping an API that silently didn't provide the atomicity it promised.

Cassandra will let you write a query that triggers a full-cluster scatter-gather scan, and it will degrade a production cluster badly under load. Most ORMs don't stop you.

Kandra's predicate query DSL (find {} / findAll {}) structurally cannot express ALLOW FILTERING — every predicate resolves through a partition key, @LookupIndex, or @SecondaryIndex, or the query throws at build time. The one exception is findActive() on @SoftDelete entities, which always scans the whole table with ALLOW FILTERING — logged with a WARN naming the cost, not silent, but not something the DSL stops you from reaching for.

Naive DELETE-heavy workloads generate tombstones that degrade read performance until compaction catches up, days later by default. Most relational-background developers have never had to think about this.

@SoftDelete uses a TTL, not a DELETE. And when deleteAll() would actually generate a lot of tombstones, it logs an explicit WARN with the count — before it becomes a 3am page.

Lightweight Transactions (Paxos-based) give you real compare-and-set semantics, but at a real latency cost most relational developers have never had to reason about — SQL transactions don't ask you to.

Plain writes are the default path. @Version and saveIfNotExists are something you opt into deliberately, visible in the entity definition — not hidden behind a @Transactional that quietly does something different per isolation level.

Partition-scoped design (or its absence) is invisible on a small dev dataset and catastrophic at scale.

Kandra's schema and query validation run at plugin install — startup — not first request. A query that can't be served without a full scan is caught before deploy, not discovered under load.