UUID Keys in Redis, DynamoDB, and Cassandra

NoSQL databases are often deployed in distributed, multi-node configurations where generating unique IDs without a central coordinator is essential. UUID v4 is a natural fit: it's random, globally unique, and requires no database round-trip. Each NoSQL database treats UUIDs differently — Redis as string keys, DynamoDB as partition key values, and Cassandra with native UUID and TIMEUUID column types.

Redis: UUID Key Design and Namespace Prefixes

Redis is a key-value store — UUIDs work as keys directly, but the standard practice is to prefix by entity type to avoid collisions and simplify key scanning:

# Key format: {type}:{uuid}
order:550e8400-e29b-41d4-a716-446655440000
session:a7c4e2d1-5b3f-4f8e-9c1a-2d3e4f5a6b7c
user:b2c1d3e4-f5a6-4b7c-8d9e-0f1a2b3c4d5e

# Node.js example
const { createClient } = require('redis');
const { v4: uuidv4 } = require('uuid');

const client = createClient();

async function createSession(userId) {
  const sessionId = uuidv4();
  const key = `session:${sessionId}`;

  await client.hSet(key, {
    userId,
    createdAt: Date.now(),
    lastSeen: Date.now(),
  });
  await client.expire(key, 3600);  // 1 hour TTL

  return sessionId;  // return to client as session token
}

async function getSession(sessionId) {
  return client.hGetAll(`session:${sessionId}`);
}

The prefix pattern also makes SCAN and KEYS queries manageable — SCAN 0 MATCH session:* COUNT 100 returns only session keys.

DynamoDB: UUID as Partition Key

DynamoDB distributes data across partitions using a hash of the partition key. UUID v4's randomness makes it ideal — data spreads evenly, avoiding "hot partition" problems that occur with sequential integer or timestamp keys.

# Table definition (AWS CDK)
const ordersTable = new dynamodb.Table(this, 'Orders', {
  partitionKey: {
    name: 'id',
    type: dynamodb.AttributeType.STRING,  // UUID stored as string
  },
  billingMode: dynamodb.BillingMode.PAY_PER_REQUEST,
});

# Creating an item (Node.js SDK v3)
import { DynamoDBClient, PutItemCommand } from '@aws-sdk/client-dynamodb';
import { v4 as uuidv4 } from 'uuid';

const client = new DynamoDBClient({ region: 'us-east-1' });

const orderId = uuidv4();
await client.send(new PutItemCommand({
  TableName: 'Orders',
  Item: {
    id: { S: orderId },
    customerEmail: { S: '[email protected]' },
    total: { N: '49.99' },
    createdAt: { S: new Date().toISOString() },
  },
}));

DynamoDB stores UUID as a string (S type). For range queries by time, add a sort key like createdAt (ISO 8601 string sorts lexicographically, which matches chronological order).

Sell Custom Apparel — We Handle Printing & Free Shipping

Cassandra: Native UUID and TIMEUUID Types

Cassandra has two UUID-related column types:

• UUID — stores any UUID version. Use for random IDs (v4).
• TIMEUUID — stores UUID v1 only, embeds a timestamp. Cassandra provides now() to generate one and dateOf() / unixTimestampOf() to extract the timestamp back out.

-- Table using UUID primary key
CREATE TABLE orders (
    id UUID PRIMARY KEY,
    customer_email TEXT,
    total DECIMAL,
    created_at TIMESTAMP
);

-- Insert with UUID.randomUUID() in application code or uuid() in CQL
INSERT INTO orders (id, customer_email, total, created_at)
VALUES (uuid(), '[email protected]', 49.99, toTimestamp(now()));

-- Table using TIMEUUID for time-sorted queries
CREATE TABLE events (
    stream_id UUID,
    event_id TIMEUUID,
    payload TEXT,
    PRIMARY KEY (stream_id, event_id)
) WITH CLUSTERING ORDER BY (event_id ASC);

-- Query events for a stream, newest first
SELECT * FROM events
WHERE stream_id = 550e8400-e29b-41d4-a716-446655440000
ORDER BY event_id DESC;

TIMEUUID is the standard approach for time-series data in Cassandra — it gives you chronological ordering within a partition without a separate timestamp column.

Hot Key Problem: When NOT to Use UUID in NoSQL

UUID's randomness is usually an advantage, but there's one case where it creates problems: access patterns that always need the most recent N items.

With random UUID keys, "get the 10 most recent orders" requires either:

• A secondary index on createdAt (DynamoDB GSI, Cassandra secondary index) — adds cost and latency.
• A time-bucketed partition key like date:2026-04-14 and a UUID or TIMEUUID sort key — keeps recent data co-located.

For high-write, time-ordered use cases (event streams, audit logs, activity feeds), ULID or UUID v7 are better choices than UUID v4 — they embed a timestamp prefix that enables range scans while remaining sortable.

Which UUID Strategy to Use per Database

Quick reference:

Database	UUID Type	Best For
Redis	String (UUID v4)	Session tokens, cache keys, idempotency keys
DynamoDB	String (UUID v4)	Entity partition keys — even distribution, no hot partitions
DynamoDB time-series	String (ULID or UUID v7)	Sort key for time-ordered queries within a partition
Cassandra	UUID type	Random primary keys, cross-service identifiers
Cassandra time-series	TIMEUUID type	Event streams, logs — built-in timestamp extraction

Use the free UUID generator above to create test values for local development, manual DynamoDB console inserts, or Redis CLI testing.

Frequently Asked Questions

Does DynamoDB support a native UUID type?

No. DynamoDB stores UUIDs as strings (S type). The hyphenated UUID format works fine — DynamoDB hashes the string for partition routing regardless of format.

What is the difference between UUID and TIMEUUID in Cassandra?

UUID accepts any UUID version (typically v4 for random keys). TIMEUUID accepts only UUID v1, which encodes a timestamp and MAC address — Cassandra's now() function generates TIMEUUID values. TIMEUUID enables built-in time-range queries.

Is UUID v4 random enough for DynamoDB partition distribution?

Yes. UUID v4 uses 122 bits of randomness, producing an effectively uniform distribution across DynamoDB partitions. It's far better than sequential integers or timestamps.

Should Redis keys use UUID with or without hyphens?

Either works — Redis treats keys as byte arrays. Without hyphens saves 4 bytes per key, which matters at scale (billions of keys). With hyphens is more readable for debugging.