Cassandra TTL & Cassandra CQL Data Types (Example)
David Carter
⚡ Smart Summary
Cassandra Data Types define what each column may hold, and TTL controls how long a value survives before it expires automatically. This page lists every CQL type, explains the expiration mechanism, and covers the tombstone behaviour that follows expiry.
Cassandra Data Types
Cassandra supports different types of data types. Here is the table that shows data types, their constants, and description.
| CQL Type | Constants | Description |
|---|---|---|
| ascii | Strings | US-Ascii character string |
| bigint | Integers | 64-bit signed long |
| blob | Blobs | Arbitrary bytes in hexadecimal |
| boolean | Booleans | True or false |
| counter | Integers | Distributed counter values 64 bit |
| date | Integers, strings | Calendar date with no time component |
| decimal | Integers, floats | Variable precision decimal |
| double | Integers, floats | 64-bit floating point |
| duration | Duration | A span of months, days, and nanoseconds |
| float | Integers, floats | 32-bit floating point |
| frozen | Tuples, collections, user defined types | Stores a multi-part value as one immutable blob |
| inet | Strings | IP address in IPv4 or IPv6 format |
| int | Integers | 32-bit signed integer |
| list | Ordered collection of elements | |
| map | JSON style collection of key and value pairs | |
| set | Unordered collection of unique elements | |
| smallint | Integers | 16-bit signed integer |
| text | Strings | UTF-8 encoded string |
| time | Integers, strings | Time of day with nanosecond precision |
| timestamp | Integers, strings | Date plus time, encoded as milliseconds since epoch |
| timeuuid | UUIDs | Type 1 UUID, sortable by embedded time |
| tinyint | Integers | 8-bit signed integer |
| tuple | A fixed group of typed fields | |
| uuid | UUIDs | Standard UUID |
| varchar | Strings | UTF-8 encoded string, an alias of text |
| varint | Integers | Arbitrary precision integer |
Three choices in that list cause most modelling mistakes, so they are worth stating explicitly.
- text against varchar. They are the same type. Either name works, and mixing them adds no value.
- timestamp against timeuuid. Use timestamp to record when something happened. Use timeuuid as a clustering column when many events share a millisecond, because the UUID guarantees uniqueness while still sorting by time.
- decimal against double. Monetary values belong in decimal. A double introduces binary rounding error that accumulates across aggregations.
A counter column carries a special restriction: a table may hold counter columns or ordinary columns, never both, and counter rows cannot be inserted, only incremented.
Cassandra TTL (Time to Live) using Automatic Data Expiration
Cassandra provides functionality by which data can be automatically expired.
During data insertion, you have to specify ‘ttl’ value in seconds. ‘ttl’ value is the time to live value for the data. After that particular amount of time, data will be automatically removed.
For example, specify ttl value 100 seconds during insertion. Data will be automatically deleted after 100 seconds. When data is expired, that expired data is marked with a tombstone.
A tombstone exists for a grace period. After data is expired, data is automatically removed after compaction process.
Syntax
INSERT INTO KeyspaceName.TableName (ColumnNames) VALUES (ColumnValues) USING TTL TimeInSeconds;
Example
Here is the snapshot where data is being inserted in Student table with ttl value of 100 seconds.
INSERT INTO University.Student (rollno, name, dept, semester) VALUES (3, 'Guru99', 'CS', 7) USING TTL 100;
Here is the snapshot where data is automatically expired after 100 seconds and data is automatically removed.
Checking and Changing TTL on Existing Data
Once a value carries a TTL, three further operations are useful, and each has a behaviour that surprises newcomers.
The remaining lifetime of any non-primary-key column can be read with the TTL function.
SELECT name, TTL(name) FROM University.Student WHERE rollno = 3;
A null result means the column has no expiry set. Primary key columns cannot be queried this way, because the TTL attaches to the values rather than to the key.
An existing value can be given a new TTL by updating it, which resets the countdown from that moment.
UPDATE University.Student USING TTL 600 SET name = 'Guru99' WHERE rollno = 3;
A table-wide default avoids repeating the clause on every statement.
ALTER TABLE University.Student WITH default_time_to_live = 86400;
Two consequences follow. First, TTL applies per column, not per row, so updating one column without a TTL leaves that column behind after the rest expires, producing a partially populated row. Setting the TTL on the whole insert avoids this. Second, every expiry writes a tombstone, so a table where millions of rows expire together will slow reads until compaction clears them. Using TimeWindowCompactionStrategy for such tables lets whole SSTables be dropped at once rather than compacted row by row.
Expiry can also be applied to elements inside a collection, which is covered in the Cassandra collections tutorial.
