INSERT, SELECT, UPDATE, DELETE, TTL, and Basic CQL Operations
Master everyday Cassandra query language operations and understand how data mutations behave in a distributed system.
Inside this chapter
- Basic CQL Mutation Flow
- Inserting and Reading Data
- Updates, Deletes, and TTL
- Delete Behavior and Tombstones
Series navigation
Study the chapters in order for the clearest path from beginner Cassandra concepts to advanced distributed operations. Use the navigation at the bottom of each page to move through the full series.
Basic CQL Mutation Flow
Cassandra uses CQL, or Cassandra Query Language, which looks similar to SQL in some places but behaves differently in important ways. Inserts and updates are both mutations, and data access is governed strongly by the table’s primary key shape.
Inserting and Reading Data
INSERT INTO user_activity (user_id, activity_time, activity_type, details)
VALUES (uuid(), toTimestamp(now()), 'LOGIN', 'User logged in');
SELECT user_id, activity_time, activity_type
FROM user_activity
WHERE user_id = 2b8f5f30-1111-4444-9999-123456789abc;Notice that Cassandra expects queries aligned with the partition key and clustering design. Arbitrary filtering is not what the database is optimized for.
Updates, Deletes, and TTL
UPDATE user_activity
USING TTL 3600
SET details = 'Session refreshed'
WHERE user_id = 2b8f5f30-1111-4444-9999-123456789abc
AND activity_time = '2026-04-16 10:30:00';TTL, or time to live, is very useful in Cassandra for expiring temporary or time-bound records automatically. This is common in session stores, telemetry buffers, and transient data sets.
Delete Behavior and Tombstones
Deletes in Cassandra do not behave exactly like hard row removal in a simple single-node relational system. They create tombstones, which are markers used in distributed deletion handling. Students should know early that excessive tombstones can create operational and performance problems later.