CQL data types

Describes CQL column types.

Data type is declared and enforced for each column in a table.

String types

INSERT or UPDATE string values in single quotes; additional escaping is required for field values that contain single quotes, see Escaping characters. For example, lastname = 'Smith'.

US-ASCII characters.`
UTF-8 encoded string.
UTF-8 encoded string.

Numeric types

INSERT or UPDATE numeric values without quotes. For example, age = 31.


8-bit signed integer.
16-bit signed integer.
32-bit signed integer.
64-bit signed integer.
Arbitrary-precision integer.


The default decimal separator is a period (.); change the decimal separator in the driver settings or using cqlshrc decimalsep option. Internally the decimal separator is stored as a period.

Variable-precision decimal, supports integers and floats.
Note: When dealing with currency, it is a best practice to have a currency class that serializes to and from an int or use the decimal form.
32-bit IEEE-754 floating point.
64-bit IEEE-754 floating point.

Date and time types

INSERT or UPDATE date/time values using single quotes around string format or no quotes for integers. For example, setting a date in string format purchase_date = '2017-05-12' vs specifying it as an integer in days since epoch purchase_date = 17298.

32-bit unsigned integer representing the number of days since epoch (January 1, 1970) with no corresponding time value.

INSERT or UPDATE values as an integer (days since epoch) or in string format 'yyyy-mm-dd', for example '2017-05-13'.

Note: When loading data from CSV use datetimeformat option in a cqlshrc file to change the cqlsh COPY date parsing format.
Signed 64-bit integer representing an amount of time in nanoseconds.
Encoded 64-bit signed integers representing the number of nanoseconds since midnight with no corresponding date value.

INSERT or UPDATE string format is 'hh:mm:ss[.fff]', where milliseconds (f) are optional.

64-bit signed integer representing the date and time since epoch (January 1 1970 at 00:00:00 GMT) in milliseconds.

INSERT or UPDATE string format is ISO-8601; the string must contain the date and optionally can include the time and time zone, 'yyyy-mm-dd [hh:MM:ss[.fff]][+/-NNNN]' where NNNN is the RFC 822 4-digit time zone specification (+0000 refers to GMT and US PST is -0800). If no time zone is specified, the client timezone is assumed. For example '2015-05-03 13:30:54.234-0800', '2015-05-03 13:30:54+0400', or '2015-05-03'.

Unique identifiers

128 bit universally unique identifier (UUID). Generate with the UUID function.
Version 1 UUID; unique identifier that includes a“conflict-free” timestamp. Generate with the NOW function.

Specialized types

Arbitrary bytes (no validation), expressed as hexadecimal. See Blob conversion functions.
True or false. Stored internally as true or false; when using the COPY in cqlsh to import or export data, change the format using the boolstyle option, for example when importing survey results that have yes/no style answer column.
64-bit signed integer. Only one counter column is allowed per table. All other columns in a counter table must be PRIMARY KEYs. Increment and decrement the counter with an UPDATE statement using the + and - operators. Null values are not supported in the counter column, the initial count equals 0.
IP address string in IPv4 or IPv6 format.

Collection types

CQL supports storing multiple values in a single column. Use collections to store or denormalize small amounts of data, such as phone numbers, tags, or addresses. Collections are not appropriate for data that is expected to grow unbounded, such as all events for a particular user; instead use a table with clustering columns.

Non-frozen collections have the following characteristics and limitations:
  • Because collections are not indexed or paged internally, the entire collection is read in order to access a single element.
  • Some operations on lists incur a read-before-write. Also list operations are not idempotent by nature and can cause timeout issues in the case of retries. INSERT on sets and maps never incur a read-before-write internally, therefore DataStax recommends sets over lists whenever possible.
Restriction: Storing a large amount of data in a single collection is an anti-pattern and therefore not supported.
Use frozen on a set, map, or list to serialize multiple components into a single value, frozen<collection_definition>. Non-frozen types allow updates to individual fields, but values in a frozen collection are treated like blobs, any upsert overwrites the entire value.
Comma separated list of non-unique values of the same data type, list<data_type>. Elements are ordered by their position in the list; the first position is zero. Supports appending and prepending elements in INSERT and UPDATE statements using the + and - operators.
Warning: Lists have limitations and performance impact, whenever possible use set or a frozen list, for example frozen<list<int>>. The append and prepend operations are not idempotent. If either of these operations timeout, the retry operation may (or may not) result in appending/prepending the value twice.
Set of key-value pairs, where keys are unique and the map is sorted by its keys, map<data_type[, data_type,...]>.
Note: For INSERT and UPDATE, setting TTL is only apply to the newly inserted/updated elements.
Comma separated list of unique values sorted by position starting at zero. Only supports replacing the entire set using INSERT and UPDATE; using operators + and - to add values is not supported.
Fixed length set of elements of different types. Unlike other collection types, a tuple is always frozen (without the need of the frozen keyword). The entire field is overwritten when using INSERT and UPDATE, therefore the expressions must provide a value for each element; explicitly declare null for elements that have no value. Tuples can contain tuples, for example tuple<int,tuple<text,text>,boolean> and also be specified as a data type of another collection type, for example set<tuple<text,inet>.
user defined type (UDT)
Customize collection type that belongs to a specific keyspace. The UDT is only available in the keyspace where it is created. The system_schema.types contains a list of all UDT, the keyspace_name, type_name, field_names, and field_types.

Deprecated types

The following types are supported for backward compatibility only.

custom type
Deprecated supported for backward compatibility. Customized type added as a sub-class to AbstractType, where the class name is fully qualified or relative to the org.apache.cassandra.db.marshal package.
Note: Replaced by user defined type (UDT).