Cassandra Collections: Set, List & Map in CQL with Example
โก Smart Summary
Cassandra Collections store several values inside a single column using the set, list, and map types. This page explains each type, the CQL syntax for creating and populating them, how to update elements, and the size limits that decide when a collection is the wrong choice.

What are Cassandra Collections?
Cassandra collections are a good way for handling tasks. Multiple elements can be stored in collections. There are limitations in Cassandra collections.
- A collection column cannot store more than 64 KB of data in a single value.
- Keep a collection small to prevent the overhead of querying collection, because the entire collection is read even when only one element is needed.
- Storing more than 64 KB means only the first 64 KB can be queried, which results in loss of data.
- An unfrozen collection is limited to roughly 65,535 elements, and every element is read together as one unit.
These limits point to one rule: collections suit a handful of attributes attached to a row, not an open-ended list that grows with usage. Anything that keeps growing belongs in clustering columns of its own table.
Types of Cassandra Collections
There are mainly three types of collections that Cassandra supports:
- Set
- List
- Map
Cassandra Set Collection
A Set stores group of elements that returns sorted elements when querying.
Syntax
Here is the syntax of the Set collection that store multiple email addresses for the teacher.
CREATE TABLE University.Teacher ( id int, Name text, Email set<text>, PRIMARY KEY (id) );
Example
Here is the snapshot where table “Teacher” is created with “Email” column as a collection.
Here is the snapshot where data is being inserted in the collection.
INSERT INTO University.Teacher (id, Name, Email) VALUES (1, 'Guru99', {'abc@gmail.com', 'xyz@hotmail.com'});
Individual elements are added or removed without rewriting the whole set, which is the main advantage of leaving a collection unfrozen.
UPDATE University.Teacher SET Email = Email + {'new@guru99.com'} WHERE id = 1; UPDATE University.Teacher SET Email = Email - {'xyz@hotmail.com'} WHERE id = 1;
Cassandra List Collection
When the order of elements matters, the list is used.
Example
Here is the snapshot where column courses of list type is added in table “Teacher.”
ALTER TABLE University.Teacher ADD coursenames list<text>;
Here is the snapshot where data is being inserted in column “coursenames”.
INSERT INTO University.Teacher (id, Name, Email, coursenames) VALUES (2, 'Hamilton', {'hamilton@hotmail.com'}, ['Data Science']);
Here is the snapshot that shows the current database state after insertion.
Elements can be appended or prepended, though prepending and updating by index both require Cassandra to read the list first, which makes them slower than appending.
UPDATE University.Teacher SET coursenames = coursenames + ['Machine Learning'] WHERE id = 2; UPDATE University.Teacher SET coursenames = ['Statistics'] + coursenames WHERE id = 2;
Cassandra Map Collection
The map is a collection type that is used to store key value pairs. As its name implies that it maps one thing to another.
For example, if you want to save course name with its prerequisite course name, map collection can be used.
Example
Here is the snapshot where map type is created for course name and its prerequisite course name.
CREATE TABLE University.Course ( id int, prereq map<text, text>, PRIMARY KEY (id) );
Here is the snapshot where data is being inserted in map collection type.
INSERT INTO University.Course (id, prereq) VALUES (1, {'DataScience': 'Database', 'Neural Network': 'Artificial Intelligence'});
A single entry is set or removed without touching the rest of the map.
UPDATE University.Course SET prereq['Robotics'] = 'Linear Algebra' WHERE id = 1; DELETE prereq['DataScience'] FROM University.Course WHERE id = 1;
Set vs List vs Map: Choosing a Collection
The three types look interchangeable but differ in ordering guarantees and update cost.
| Aspect | Set | List | Map |
|---|---|---|---|
| Ordering | Sorted by value | Insertion order preserved | Sorted by key |
| Duplicates | Not allowed | Allowed | Keys unique |
| Update cost | Cheap, no read required | Append cheap; prepend and index update require a read | Cheap per key |
| Best for | Tags, email addresses, unique labels | Ordered steps where duplicates are meaningful | Named attributes with unpredictable keys |
Prefer a set over a list unless order genuinely matters, because list index operations create tombstones and can produce surprising results under concurrent writes. Adding frozen to any of the three stores it as one immutable value, which allows the collection to appear in a primary key but removes element-level updates.
CREATE TABLE University.Enrolment ( id int, tags frozen<set<text>>, PRIMARY KEY (id, tags) );
When a collection would exceed a few dozen elements, model it as a separate table with the element as a clustering column instead, following the approach in the Cassandra data model rules. Filtering on collection contents requires an index, covered in the create and drop index tutorial.






