Twitter Snowflake to Date - Convert Twitter IDs to Dates Online

// JavaScript
const TWITTER_EPOCH = 1288834974657n;
const id = 1382350606417817604n;
const timestamp = Number((id >> 22n) + TWITTER_EPOCH);
const date = new Date(timestamp);
console.log(date); // April 18, 2021

Twitter Snowflake vs UUID — Comparison and Examples

Snowflake IDs and UUIDs both solve the problem of generating unique identifiers in distributed systems, but they have different characteristics. Here's a practical comparison with code examples.

Format Comparison

// UUID v4 — 128-bit random identifier
const uuid = "550e8400-e29b-41d4-a716-446655440000";
// 36 characters, 32 hex digits + 4 hyphens
// Completely random — no embedded timestamp

// Twitter Snowflake ID — 64-bit time-ordered integer
const snowflake = "1529877576591609861";
// 19 digits, 8 bytes
// Encodes timestamp + datacenter + worker + sequence

Generating Each Type

// JavaScript — generate UUID v4
const uuid = crypto.randomUUID();
console.log(uuid); // "550e8400-e29b-41d4-a716-446655440000"

// JavaScript — generate a Snowflake-style ID
// (simplified — real Snowflake requires a worker ID)
function generateSnowflakeId(workerId = 1) {
  const EPOCH = 1288834974657n;
  const tsMs = BigInt(Date.now()) - EPOCH;
  const sequence = BigInt(Math.floor(Math.random() * 4096));
  const worker = BigInt(workerId & 0x1F);
  
  return ((tsMs << 22n) | (worker << 12n) | sequence).toString();
}

console.log(generateSnowflakeId()); // e.g., "1529877576591609861"

# Python — generate UUID v4
import uuid
uid = str(uuid.uuid4())
print(uid)  # "550e8400-e29b-41d4-a716-446655440000"

# Python — generate a Snowflake-style ID
import time
import random

def generate_snowflake(worker_id=1):
    EPOCH_MS = 1288834974657
    ts_ms = int(time.time() * 1000) - EPOCH_MS
    sequence = random.randint(0, 4095)
    return (ts_ms << 22) | ((worker_id & 0x1F) << 12) | sequence

print(generate_snowflake())

Database Performance Comparison

-- SQL — UUID v4 as primary key (causes index fragmentation)
CREATE TABLE events_uuid (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    data TEXT,
    created_at TIMESTAMP DEFAULT NOW()
);

-- SQL — Snowflake ID as primary key (monotonically increasing = no fragmentation)
CREATE TABLE events_snowflake (
    id BIGINT PRIMARY KEY,  -- Snowflake ID generated by application
    data TEXT,
    created_at TIMESTAMP DEFAULT NOW()
);

-- SQL — UUID v7 as primary key (time-ordered UUID, best of both worlds)
CREATE TABLE events_uuid7 (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),  -- Use UUID v7 generator
    data TEXT,
    created_at TIMESTAMP DEFAULT NOW()
);

Sortability Comparison

// UUID v4 — no meaningful sort order
const uuids = [
  "550e8400-e29b-41d4-a716-446655440000",
  "6ba7b810-9dad-11d1-80b4-00c04fd430c8",
  "6ba7b811-9dad-11d1-80b4-00c04fd430c8",
];
uuids.sort(); // Alphabetical — no temporal meaning

// Snowflake IDs — sort chronologically
const snowflakes = [
  "1529877576591609861",  // May 2022
  "1700000000000000000",  // Later
  "1800000000000000000",  // Even later
];
snowflakes.sort((a, b) => (BigInt(a) < BigInt(b) ? -1 : 1));
// Sorted chronologically — higher ID = created later

Extracting Timestamps

// UUID v4 — no timestamp embedded
const uuid = "550e8400-e29b-41d4-a716-446655440000";
// Cannot extract creation time from UUID v4

// Snowflake ID — timestamp embedded
const snowflake = "1529877576591609861";
const TWITTER_EPOCH = 1288834974657n;
const tsMs = (BigInt(snowflake) >> 22n) + TWITTER_EPOCH;
console.log(new Date(Number(tsMs)).toISOString()); // Creation time!

// UUID v7 — timestamp embedded (newer standard)
// First 48 bits encode Unix timestamp in milliseconds
// Provides sortability + timestamp extraction like Snowflake

Storage Size Comparison

-- Storage comparison for 1 billion rows

-- UUID v4 as CHAR(36): 36 bytes per row = 36 GB
-- UUID v4 as BINARY(16): 16 bytes per row = 16 GB
-- Snowflake as BIGINT: 8 bytes per row = 8 GB

-- Index size comparison (B-tree index on primary key)
-- UUID v4: large, fragmented index due to random inserts
-- Snowflake: compact, sequential index — always appends to end

-- Query performance for range queries
-- UUID v4: full table scan or inefficient index scan
-- Snowflake: efficient index range scan (IDs are time-ordered)

When to Use Each

• Use Snowflake IDs when: high-write databases, time-ordered data, need embedded timestamps, storage efficiency matters
• Use UUID v4 when: maximum compatibility needed, no central coordination possible, creation time must be hidden, 128-bit uniqueness required
• Use UUID v7 when: you want time-ordering + UUID ecosystem compatibility (newer standard, growing support)

Security Considerations

// UUID v4 — unpredictable, harder to enumerate
const uuid = crypto.randomUUID();
// Attacker cannot guess adjacent UUIDs

// Snowflake ID — sequential, easier to enumerate
const snowflake = "1529877576591609861";
// Attacker can guess nearby IDs by incrementing/decrementing
// Mitigation: always enforce authorization checks regardless of ID format

// Best practice: never rely on ID unpredictability for security
// Always check authorization: "can this user access this resource?"

Quick Reference

• UUID v4: 128 bits, random, 36 chars, no timestamp, universal support
• Snowflake: 64 bits, time-ordered, 19 digits, has timestamp, requires worker ID
• UUID v7: 128 bits, time-ordered, 36 chars, has timestamp, growing support
• ULID: 128 bits, time-ordered, 26 chars, has timestamp, no worker ID needed

For most new high-performance applications, Snowflake IDs or UUID v7 are better choices than UUID v4. The time-ordering property dramatically improves database performance at scale and provides useful metadata without additional storage.