Cassandra Data Types

Every column in a Cassandra table has a data type that tells Cassandra what kind of value it stores. Choosing the right data type ensures efficient storage, correct sorting, and proper query behavior. CQL supports a rich set of built-in types covering text, numbers, dates, identifiers, and collections.

Text Types

TEXT and VARCHAR

Both TEXT and VARCHAR store UTF-8 encoded strings of any length. They are functionally identical in Cassandra. Use TEXT for all human-readable strings — names, descriptions, email addresses, and free-form content.

CREATE TABLE articles (
  article_id UUID PRIMARY KEY,
  title      TEXT,
  body       TEXT,
  author     TEXT
);

ASCII

ASCII stores strings that contain only US-ASCII characters (letters, digits, and basic punctuation). It rejects any character outside that set. Use it when you are certain the data never contains accented characters or non-Latin scripts.

Numeric Types

Type       Size     Range                              Use Case
──────────────────────────────────────────────────────────────────────
TINYINT    1 byte   -128 to 127                        Small counters
SMALLINT   2 bytes  -32,768 to 32,767                  Small numbers
INT        4 bytes  -2.1B to 2.1B                      General integers
BIGINT     8 bytes  -9.2Q to 9.2Q                      Large IDs, counts
FLOAT      4 bytes  ~7 decimal digits precision         Coordinates
DOUBLE     8 bytes  ~15 decimal digits precision        Scientific data
DECIMAL    Variable Arbitrary precision                 Money, finance
VARINT     Variable Arbitrary size integer              Very large nums

DECIMAL for Money

Never store currency values in FLOAT or DOUBLE. Floating-point types cannot represent decimal fractions exactly, which causes rounding errors. Use DECIMAL for any financial calculation.

-- Wrong:
price FLOAT   -- 29.99 might be stored as 29.98999999...

-- Correct:
price DECIMAL -- 29.99 stored exactly

Boolean

BOOLEAN stores either true or false.

CREATE TABLE accounts (
  account_id UUID PRIMARY KEY,
  username   TEXT,
  is_active  BOOLEAN,
  is_admin   BOOLEAN
);

INSERT INTO accounts (account_id, username, is_active, is_admin)
VALUES (uuid(), 'alice', true, false);

Date and Time Types

TIMESTAMP

TIMESTAMP stores a date and time down to millisecond precision. Internally it holds the number of milliseconds since January 1, 1970 (Unix epoch). It is the most commonly used date-time type in Cassandra.

CREATE TABLE events (
  event_id   UUID,
  occurred   TIMESTAMP,
  PRIMARY KEY (event_id)
);

INSERT INTO events (event_id, occurred)
VALUES (uuid(), toTimestamp(now()));

DATE

DATE stores only the date — year, month, and day — without any time component. Use it for birthdays, deadlines, and calendar entries.

birthday DATE  -- stores '1990-07-15'

TIME

TIME stores only the time of day in nanosecond precision, without a date. Use it for scheduled times such as opening hours.

opens_at TIME  -- stores '09:00:00'

UUID and TIMEUUID

UUID

UUID (Universally Unique Identifier) generates a 128-bit value guaranteed to be unique across all machines and all time. Use it for primary keys where you need a globally unique identifier. Generate one in CQL with the uuid() function.

product_id UUID DEFAULT uuid()

TIMEUUID

TIMEUUID is a version 1 UUID that embeds a timestamp. Because it includes the time of creation, rows using TIMEUUID as a clustering column sort chronologically. Generate one in CQL with now().

CREATE TABLE audit_log (
  user_id   UUID,
  log_id    TIMEUUID,
  action    TEXT,
  PRIMARY KEY (user_id, log_id)
) WITH CLUSTERING ORDER BY (log_id ASC);

INSERT INTO audit_log (user_id, log_id, action)
VALUES ([user-uuid], now(), 'login');

UUID vs TIMEUUID Comparison

Property         UUID                    TIMEUUID
──────────────────────────────────────────────────────────────
Contains time?   No (random)             Yes (embedded timestamp)
Sort order       Random                  Chronological
Generate in CQL  uuid()                  now()
Good for         Unique IDs for rows     Time-ordered event logs

BLOB

BLOB (Binary Large Object) stores arbitrary binary data as a sequence of bytes. Use it for images, files, or serialized objects. Keep BLOB values small — storing large binary data in Cassandra causes large partitions and slow reads. For files larger than a few kilobytes, store only the file path or URL in Cassandra and keep the actual file in object storage like Amazon S3.

thumbnail BLOB  -- small image bytes

INET

INET stores an IPv4 or IPv6 address as a string in human-readable notation.

CREATE TABLE server_logs (
  log_id      UUID PRIMARY KEY,
  source_ip   INET,
  message     TEXT
);

INSERT INTO server_logs (log_id, source_ip, message)
VALUES (uuid(), '192.168.1.100', 'Request received');

COUNTER

COUNTER stores a 64-bit integer that can only be incremented or decremented, never set to an arbitrary value. Use it for tallies — page views, likes, downloads. All non-primary-key columns in a counter table must be of type COUNTER.

CREATE TABLE page_views (
  page_id   TEXT PRIMARY KEY,
  views     COUNTER
);

UPDATE page_views SET views = views + 1 WHERE page_id = '/home';

Choosing the Right Type

Scenario                     Best Type
──────────────────────────────────────────────────────────────
User name, description       TEXT
Price, salary, currency      DECIMAL
Age, quantity (small)        INT
Row unique ID                UUID
Time-ordered log ID          TIMEUUID
Event timestamp              TIMESTAMP
Birthday, calendar date      DATE
Active/inactive flag         BOOLEAN
IP address                   INET
Counting views, likes        COUNTER

Summary

Cassandra provides data types for every common use case — text, numbers, dates, identifiers, and binary data. Choose DECIMAL for money, UUID or TIMEUUID for identifiers, TIMESTAMP for event times, and COUNTER for incrementing tallies. Using the correct type from the start prevents conversion headaches later and keeps your data model clean and efficient.

Previous lesson

Back to course

Next lesson