A data type defines what kind of value a column stores. In ScyllaDB, every column has one type, and all values in that column share it. Types give schema fields meaning beyond generic numbers and text: they distinguish strings, numeric values, dates, times, identifiers, durations, and collections. section 4.0 section 4.7
Choose types after identifying the fields required by each query and table. A restaurant review might need an ID, title, author ID, score, date, image gallery, review text, and restaurant; summary tables repeat the fields needed to serve author-, date-, or score-based views. The type should represent the field’s meaning and expected values. section 4.1.2 section 4.0
Select a type by matching its behavior and limits to the value you need to store:
- Use TEXT for strings; it represents characters in UTF-8. section 4.7
- Use an integer type whose range fits present and future bounds. TINYINT, SMALLINT, INT, and BIGINT trade range for storage size; values outside a type’s range fail. section 4.2.2
- Use FLOAT or DOUBLE for floating-point numbers, and DECIMAL or VARINT when arbitrarily large numeric values are needed. section 4.2.2
- Use TIMESTAMP for date and time together, DATE or TIME when only one is needed, and DURATION for a length of time. section 4.7
- Use UUID for unique identifiers and TIMEUUID when temporal sorting and a conflict-free timestamp are needed. Generate UUIDs in the application when it must know the value at creation. section 4.7
- Use SET for multiple values when idempotent operations matter; use LIST cautiously because appends are not idempotent and can duplicate entries; use MAP for same-typed key/value associations. section 4.7
Sizing a review score
A review score constrained to 1–10 may appear to require a floating-point type if scores such as 7.5 are allowed. If hundredths are unnecessary, store a scaled score from 1–100 in a TINYINT and convert it to a 10-point display scale in the application. This avoids floating-point complications while using a type small enough for the actual bounds. section 4.2.2
Listing 4.1 Table to play around with data types
cqlsh:types> CREATE TABLE basic(
text TEXT, #1
ascii ASCII, #2
bigint BIGINT, #3
blob BLOB, #4
boolean BOOLEAN, #5
date DATE, #6
decimal DECIMAL, #7
double DOUBLE, #8
duration DURATION, #9
float FLOAT, #10
inet INET, #11
int INT, #12
smallint SMALLINT, #13
time TIME, #14
timestamp TIMESTAMP, #15
timeuuid TIMEUUID, #16
tinyint TINYINT, #17
uuid UUID, #18
varchar VARCHAR, #19
varint VARINT, #20
PRIMARY KEY (text)
);
Use this playground table to inspect the basic CQL types side by side and experiment without needing to populate every non-primary-key column; such columns are nullable and omitted values are not written. section 4.1.1
Type choice has operational consequences. An oversized numeric type wastes database space, while an undersized one eventually rejects valid values. Collection choice also affects write safety: SET operations are idempotent, whereas repeated LIST appends can create duplicates. Model these trade-offs around requirements rather than treating types as interchangeable storage labels. section 4.2.2 section 4.7
