A TIMEUUID is ScyllaDB’s timestamp-bearing UUID type. It implements a version 1 UUID: a unique 128-bit identifier with time encoded inside it. Unlike a predominantly random UUID, TIMEUUID values sort by generation time, so an identifier can also express when its row was created. section 4.4.1
Use TIMEUUID when a record needs a conflict-free primary-key value and time order is useful to the application. Sorting IDs can return recent records in recency order without relying on a separate random identifier. A regular UUID remains suitable when only a quick, random identifier is needed. section 4.4.1 section 4.4.2
Choose an ID type from the query and data relationship it must support:
- Choose TIMEUUID for article IDs when article summaries must be shown by most recent date; time ordering avoids the arbitrary order of random UUIDs. section 4.4.2
- Choose TIMEUUID when comparing creation order across data is valuable, such as determining that one record was created before another. section 4.4.2
- Choose UUID when the timestamp has no value to the application and a random identifier is enough. section 4.4.2
- Consider another generation scheme only beyond roughly 10 million TIMEUUIDs per second. section 4.4.2
Use TIMEUUID in an articles table
A restaurant-review article can use a TIMEUUID as its primary key and its author ID as another TIMEUUID. The article ID supplies uniqueness and temporal sorting, while title, score, date, images, review text, and restaurant name remain separate fields. CREATE TABLE reviews.articles( id TIMEUUID, title TEXT, author_id TIMEUUID, score TINYINT, date DATE, images SET<FROZEN<image>>, review TEXT, restaurant_name TEXT, PRIMARY KEY (id) ); section 5.3.1
cqlsh: types> INSERT INTO basic(text, uuid, timeuuid)
VALUES ('uuids', uuid(), now());
Generate a TIMEUUID inside an INSERT with now(). ScyllaDB creates the timestamp-based ID as the row is written; use a pre-generated value instead when the application must know the ID immediately without querying again. section 4.4.1 section 6.1.1
