PostgreSQL UUIDv7 Performance Benchmark: Native vs Custom Implementations

Introduction

Choosing the right unique identifier strategy is critical for database performance and application scalability. While UUIDv4 has been the go-to choice for distributed systems, the new UUIDv7 standard introduces time-ordered identifiers that maintain randomness while providing natural sorting capabilities.

PostgreSQL 18’s introduction of native UUIDv7 support marks a turning point in this landscape. Our comprehensive benchmarking shows the native implementation lands within ~4% of UUIDv4 while adding time-ordered benefits that were previously considered a performance trade-off.

This analysis examines five different identifier implementations with real-world performance data, helping you make informed decisions for your PostgreSQL applications.

Understanding UUIDv7

Before diving into implementations, let’s understand what makes UUIDv7 special. Unlike its predecessor UUIDv4 (which is completely random), UUIDv7 incorporates a timestamp, making it naturally sortable by creation time.

The structure consists of:

• 48 bits: Unix timestamp in milliseconds
• 4 bits: Version field (0111 binary = 7)
• 12 bits: Random data or sub-millisecond precision
• 2 bits: Variant field
• 62 bits: Additional random data

This design provides both temporal ordering and sufficient randomness to prevent collisions.

UUIDv7 Implementation Approaches

PostgreSQL 18 Native Implementation

PostgreSQL 18 introduces native uuidv7() support with RFC 9562 compliance:

-- PostgreSQL 18+ native function
SELECT uuidv7();
-- Output: 01976408-e525-78fb-889c-818826fc412f

-- Optional time parameter for historical UUIDs
SELECT uuidv7('2024-01-01 00:00:00'::timestamp);

-- Extract timestamp from any UUIDv7
SELECT uuid_extract_timestamp('01976408-e525-78fb-889c-818826fc412f'::uuid);
-- Output: 2024-12-06 10:30:45.637+00

Native Implementation Features:

• C-level performance: Direct PostgreSQL core implementation
• 12-bit sub-millisecond precision: Uses rand_a field for timestamp fraction
• Monotonicity guarantee: Ensures ordering within same database session
• Built-in extraction functions: uuid_extract_timestamp(), uuid_extract_version()
• RFC 9562 compliance: Follows latest UUID standard published May 2024

PostgreSQL 18 Native Analysis

Custom UUIDv7 Implementations (PostgreSQL < 18)

Let’s examine each implementation in detail:

Implementation 1: PL/pgSQL Overlay Method (uuid_generate_v7)

CREATE OR REPLACE FUNCTION uuid_generate_v7()
RETURNS uuid
AS $$
BEGIN
  -- use random v4 uuid as starting point (which has the same variant we need)
  -- then overlay timestamp
  -- then set version 7 by flipping the 2 and 1 bit in the version 4 string
  RETURN encode(
    set_bit(
      set_bit(
        overlay(uuid_send(gen_random_uuid())
                placing substring(int8send(floor(extract(epoch from clock_timestamp()) * 1000)::bigint) from 3)
                from 1 for 6
        ),
        52, 1
      ),
      53, 1
    ),
    'hex')::uuid;
END
$$
LANGUAGE plpgsql
VOLATILE;

This implementation:

1. Generates a random UUIDv4 as the base
2. Extracts the current timestamp in milliseconds
3. Overlays the timestamp onto the first 48 bits
4. Sets the version bits to make it a valid UUIDv7

Implementation 1 Analysis

Implementation 2: Pure SQL Method (uuidv7_custom)

CREATE FUNCTION uuidv7_custom() RETURNS uuid
AS $$
  -- Replace the first 48 bits of a uuidv4 with the current
  -- number of milliseconds since 1970-01-01 UTC
  -- and set the "ver" field to 7 by setting additional bits
  SELECT encode(
    set_bit(
      set_bit(
        overlay(uuid_send(gen_random_uuid()) placing
          substring(int8send((extract(epoch from clock_timestamp())*1000)::bigint) from 3)
          from 1 for 6),
        52, 1),
      53, 1), 'hex')::uuid;
$$ LANGUAGE sql VOLATILE;

This is essentially the same algorithm as Function 1, but implemented as a pure SQL function.

Implementation 2 Analysis

Implementation 3: Sub-millisecond Precision (uuidv7_sub_ms)

CREATE FUNCTION uuidv7_sub_ms() RETURNS uuid
AS $$
SELECT encode(
  substring(int8send(floor(t_ms)::int8) from 3) ||
  int2send((7<<12)::int2 | ((t_ms-floor(t_ms))*4096)::int2) ||
  substring(uuid_send(gen_random_uuid()) from 9 for 8)
, 'hex')::uuid
FROM (SELECT extract(epoch from clock_timestamp())*1000 as t_ms) s
$$ LANGUAGE sql VOLATILE;

This implementation builds the UUID from scratch:

1. Extracts timestamp with fractional milliseconds
2. Uses the fractional part for sub-millisecond precision
3. Manually constructs the UUID by concatenating components

Implementation 3 Analysis

Implementation Flow Overview

Start UUID Generation
        ↓
  Choose Implementation
        ↓
    ┌───────────────────────────────────────┐
    │                                       │
    ↓                                       ↓
PostgreSQL 18+                    Custom Implementations
    ↓                                       ↓
Native uuidv7                      ┌───────┼───────┐
    ↓                              ↓       ↓       ↓
C-level Processing           Custom 1  Custom 2  Custom 3
    ↓                              ↓       ↓       ↓
12-bit Sub-ms Precision      Generate  Generate  Extract
    ↓                        UUIDv4    UUIDv4    Timestamp
Ensure Monotonicity          Base      Base         ↓
    ↓                          ↓       ↓       Split Integer
Return Native UUIDv7      Extract  Extract    & Fractional
    ↓                     Timestamp Timestamp      ↓
    └───────────────────────────┼───────┼─────────┘
                                ↓       ↓
                          Overlay on   Overlay on
                          48 bits     48 bits
                                ↓       ↓
                          Set Version Set Version
                          Bits to 7   Bits to 7
                                ↓       ↓
                          Return UUID Return UUID
                                └───┬───┘
                                    ↓
                               Final UUIDv7

Bit Manipulation Visualization

To better understand how Function 1 and 2 work, here’s a visual representation of the bit manipulation process:

Performance Benchmarks

To provide real-world performance data, I created a comprehensive benchmark suite testing:

• Single-threaded performance
• Concurrent generation under load
• Collision resistance
• Time ordering accuracy

Benchmark Environment Specifications:

• High-precision Testing: 100,000 iterations per run (10 runs) for statistical significance
• Warmup: 25,000 iterations per function to eliminate cold-start effects
• Runs: 10 complete benchmark cycles per function for consistency analysis
• Timing: Nanosecond precision using time.perf_counter_ns()
• Concurrency: 10 workers × 10,000 iterations (1,000 warmup) for realistic load testing
• PostgreSQL Config: 512MB shared_buffers, 2GB effective_cache_size, SSD optimizations
• Resource limits: 2GB RAM, 2 CPU cores per container

The full benchmark code and methodology are available at github.com/spa5k/uuidv7-postgres-benchmark.

Comprehensive Benchmark Results

Based on professional-grade benchmarking with 10 runs × 100,000 iterations per implementation (with warmups):

Single-Thread Performance

Key Findings

• PostgreSQL 18 native UUIDv7: Within ~4% of UUIDv4 (74.3 vs 71.6 μs) with matching throughput (~21.7K ops/sec)
• Fastest UUIDv7: uuidv7_custom on PG18 at 71.8 μs (0.6% off UUIDv4 latency)
• Throughput leader: ulid_generate on PG17 at 23,160 ops/sec; top UUIDv7 throughput on PG18 is uuid_generate_v7 at 21,877 ops/sec
• Time-ordered at no penalty: Practical parity with UUIDv4 removes the historical trade-off
• Zero-downtime migration: Drop-in replacement for existing UUIDv4 columns
• Zero collisions detected across 50,000+ generations per implementation

Collision Probability Analysis

One concern with UUIDs is collision probability. Here’s how our implementations compare:

Key insights:

• Native uuidv7(): 62 bits of randomness + 12-bit sub-millisecond precision
• Custom UUIDv7: 74 bits of randomness
• ULID: 80 bits of randomness (with time-based ordering)
• TypeID: Based on UUIDv7 with type prefix for additional validation
• Even at 1 billion UUIDs per millisecond, collision probability remains negligible
• Native implementation’s monotonicity guarantee provides additional collision protection
• Zero collisions observed in 50,000 generations across all implementations

Choosing the Right Implementation

Here’s a decision matrix to help you choose:

Use PostgreSQL 18 Native uuidv7() when:

• You’re using PostgreSQL 18+ (released 2025)
• You want the best performance AND time ordering
• You need guaranteed monotonicity within sessions
• You prefer official, maintained implementations
• You want built-in timestamp extraction functions

Use Custom Implementation 1 (uuid_generate_v7) when:

• You’re on PostgreSQL < 18
• You prefer readable, maintainable code
• You’re already using PL/pgSQL functions
• Performance is good enough (>18K UUIDs/sec concurrent)
• You want a well-documented approach

Use Custom Implementation 2 (uuidv7_custom) when:

• You’re on PostgreSQL < 18
• You prefer pure SQL functions
• You want balanced performance
• You don’t need sub-millisecond precision

Use Custom Implementation 3 (uuidv7_sub_ms) when:

• You’re on PostgreSQL < 18
• You need sub-millisecond time precision
• You’re generating many UUIDs within the same millisecond
• Time ordering accuracy is paramount
• You can accept slightly lower performance

Implementation Recommendations

1. Indexing Strategy

-- Create a B-tree index for time-based queries
CREATE INDEX idx_uuid_time ON your_table (id);

-- For composite indexes, put UUID first if it's the primary filter
CREATE INDEX idx_uuid_status ON your_table (id, status);

2. Migration from UUIDv4

-- Add new column
ALTER TABLE your_table ADD COLUMN new_id uuid DEFAULT uuidv7_custom();

-- Migrate existing data (optional)
UPDATE your_table SET new_id = uuidv7_custom() WHERE new_id IS NULL;

-- Switch primary key
ALTER TABLE your_table DROP CONSTRAINT your_table_pkey;
ALTER TABLE your_table ADD PRIMARY KEY (new_id);

3. Monitoring Performance

-- Track UUID generation performance
CREATE OR REPLACE FUNCTION benchmark_uuid_generation(
  func_name TEXT,
  iterations INT DEFAULT 1000
) RETURNS TABLE (
  avg_microseconds NUMERIC,
  total_seconds NUMERIC
) AS $$
DECLARE
  start_time TIMESTAMP;
  end_time TIMESTAMP;
BEGIN
  start_time := clock_timestamp();

  EXECUTE format('SELECT %I() FROM generate_series(1, %s)', func_name, iterations);

  end_time := clock_timestamp();

  RETURN QUERY SELECT
    EXTRACT(EPOCH FROM (end_time - start_time)) * 1000000 / iterations,
    EXTRACT(EPOCH FROM (end_time - start_time));
END;
$$ LANGUAGE plpgsql;

Production Considerations

High Availability

All three functions are deterministic based on system time, making them safe for:

• Read replicas
• Logical replication
• Multi-master setups (with proper clock synchronization)

Clock Synchronization

Storage Optimization

UUIDs are 128-bit values, stored as 16 bytes in PostgreSQL. For large tables:

• Consider using BRIN indexes for time-range queries
• Partition by time ranges that align with your UUID timestamps
• Use CLUSTER periodically to maintain physical ordering

Performance Comparison Charts

Updated Performance Results (Professional Benchmark Data)

Our professional-grade benchmarks with 10 runs × 100,000 iterations and statistical analysis reveal clear performance leaders:

Performance Rankings

Key Insights from Professional Benchmark Analysis

1. Native UUIDv7 near parity: PostgreSQL 18 native uuidv7() measures 74.3 μs vs UUIDv4 at 71.6 μs with ~21.7K ops/sec
2. Fastest UUIDv7: uuidv7_custom (PG18) at 71.8 μs; top UUIDv7 throughput is uuid_generate_v7 (PG18) at 21,877 ops/sec
3. Throughput leader overall: ulid_generate (PG17) reaches 23,160 ops/sec with human-readable IDs
4. Statistical Significance: Results based on 10 runs × 100,000 iterations with multiple runs for reliability
5. Zero Collision Rate: All implementations maintain perfect uniqueness guarantees (50k collision sample)

Multi-dimensional Performance Analysis

Implementation Architecture Overview

Understanding the architectural differences helps explain the performance characteristics:

UUID Family
├── 🔴 UUIDv4 (Baseline)
│   ├── Pure random
│   ├── No time info
│   └── PostgreSQL native
│
├── UUIDv7 Implementations
│   ├── 🔵 UUIDv7 (PL/pgSQL)
│   │   ├── Overlay method
│   │   ├── Best single-thread
│   │   └── Readable code
│   │
│   ├── 🟢 UUIDv7 (Pure SQL)
│   │   ├── Bit operations
│   │   ├── No PL/pgSQL overhead
│   │   └── Balanced performance
│   │
│   └── 🟡 UUIDv7 (Sub-ms)
│       ├── Custom precision
│       ├── Manual construction
│       └── Best time ordering
│
└── Alternative Formats
    ├── 🟠 ULID
    │   ├── Base32 encoded
    │   ├── Human readable
    │   ├── Lexicographic sort
    │   └── Compact storage
    │
    └── 🟣 TypeID
        ├── Prefixed identifiers
        ├── Type safety
        ├── Based on UUIDv7
        └── Self-documenting

Performance Characteristics:
📈 Single-threaded:    gen_random_uuid fastest → 71.4 μs (UUIDv4 baseline)
📈 Fastest UUIDv7:     uuidv7_custom (PG18) → 71.8 μs (≈0.6% off UUIDv4)
⚡ Throughput:         ulid_generate (PG17) → 23,160 ops/sec
💾 Storage:           ULID most compact → 26 bytes text

The architecture diagram reveals why certain implementations perform differently:

• UUIDv4: Direct PostgreSQL C implementation with no timestamp manipulation
• UUIDv7 variants: Add timestamp overlay operations with varying complexity
• ULID: Custom timestamp formatting with Base32 encoding overhead
• TypeID: Builds on UUIDv7 with additional prefix concatenation

Feature Comparison Matrix

Beyond UUIDv7: ULID and TypeID Alternatives

While UUIDv7 provides excellent time-ordering capabilities, there are other modern identifier formats worth considering for specific use cases. Let’s explore ULID and TypeID implementations in PostgreSQL.

ULID (Universally Unique Lexicographically Sortable Identifier)

ULID offers a human-readable alternative to UUIDs with natural lexicographic sorting:

CREATE OR REPLACE FUNCTION ulid_generate() RETURNS TEXT AS $$
DECLARE
    timestamp_ms BIGINT;
    chars TEXT := '0123456789ABCDEFGHJKMNPQRSTVWXYZ';
    result TEXT := '';
    i INT;
    idx INT;
BEGIN
    -- Get current timestamp in milliseconds
    timestamp_ms := (EXTRACT(EPOCH FROM clock_timestamp()) * 1000)::BIGINT;

    -- Create time-sortable prefix (10 chars) based on timestamp
    result := lpad(to_hex(timestamp_ms), 10, '0');

    -- Add 16 random base32 characters
    FOR i IN 1..16 LOOP
        idx := (random() * 31)::INT + 1;
        result := result || substr(chars, idx, 1);
    END LOOP;

    RETURN upper(result);
END;
$$ LANGUAGE plpgsql VOLATILE;

ULID Characteristics:

• Length: 26 characters
• Encoding: Crockford Base32 (case-insensitive)
• Example: 01ARZ3NDEKTSV4RRFFQ69G5FAV
• Storage: 26 bytes as text
• Time precision: Millisecond

TypeID (Type-safe Prefixed Identifiers)

TypeID adds type safety by prefixing identifiers with their entity type:

-- Create composite type for binary TypeID
DROP TYPE IF EXISTS typeid CASCADE;
CREATE TYPE typeid AS (
    prefix TEXT,
    uuid UUID
);

-- Function returning composite type
CREATE OR REPLACE FUNCTION typeid_generate(prefix_param TEXT DEFAULT 'obj')
RETURNS typeid AS $$
BEGIN
    RETURN ROW(prefix_param, uuidv7_custom())::typeid;
END;
$$ LANGUAGE plpgsql VOLATILE;

-- Function returning text representation
CREATE OR REPLACE FUNCTION typeid_generate_text(prefix_param TEXT DEFAULT 'obj')
RETURNS TEXT AS $$
DECLARE
    uuid_val UUID;
    chars TEXT := '0123456789ABCDEFGHJKMNPQRSTVWXYZ';
    result TEXT := '';
    i INT;
    idx INT;
BEGIN
    uuid_val := uuidv7_custom();

    -- Generate 26 characters base32-like representation
    FOR i IN 1..26 LOOP
        idx := (random() * 31)::INT + 1;
        result := result || substr(chars, idx, 1);
    END LOOP;

    RETURN prefix_param || '_' || result;
END;
$$ LANGUAGE plpgsql VOLATILE;

TypeID Characteristics:

• Format: prefix_base32encodedid
• Examples: user_01h4qm3k5n2p7r8s9t0v1w2x3y, order_01h4qm3k5n2p7r8s9t0v1w2x3y
• Storage: Variable length (prefix + 27 characters)
• Type safety: Entity type embedded in identifier

Extended Performance Comparison

Based on professional-grade benchmarking with 10 runs × 100,000 iterations per test:

Storage Efficiency Analysis

Comprehensive Performance Summary

Collision Resistance

All implementations achieved zero collisions in 50,000 ID generation tests (collision sample size), demonstrating excellent entropy and uniqueness guarantees across all identifier types.

PostgreSQL 18 Native UUIDv7 Support

PostgreSQL 18 introduces native uuidv7() support with significant advantages:

-- PostgreSQL 18+ native function
SELECT uuidv7();
-- Output: 01976408-e525-78fb-889c-818826fc412f

-- Optional time parameter
SELECT uuidv7('2024-01-01 00:00:00'::timestamp);

-- Extract timestamp from UUIDv7
SELECT uuid_extract_timestamp('01976408-e525-78fb-889c-818826fc412f'::uuid);

Native UUIDv7 Features:

• C-level implementation for maximum performance
• 12-bit sub-millisecond precision (vs 62-bit random in custom implementations)
• Monotonicity guarantee within the same database session
• Built-in extraction functions for timestamp and version
• Backward compatibility with existing UUID infrastructure

Choosing the Right Identifier

Use UUIDv7 when:

• You need maximum PostgreSQL compatibility
• Binary storage efficiency is critical (16 bytes)
• You’re already using UUID infrastructure
• Database indexing performance is a priority
• You need PostgreSQL 18’s native implementation benefits

Use ULID when:

• Human readability is important for debugging
• You need case-insensitive identifiers
• Lexicographic sorting is required in application code
• You want a single string representation without dashes
• URL safety is important (no special characters)

Use TypeID when:

• Type safety is critical for preventing ID misuse
• You have multiple entity types to identify
• API clarity and self-documentation are important
• You want to prevent accidentally using wrong ID types
• Debugging requires knowing entity type from ID alone

Implementation Recommendations

Database Schema Design

-- UUIDv7 primary keys (PostgreSQL 18+ native function)
CREATE TABLE users (
    id UUID PRIMARY KEY DEFAULT uuidv7(),  -- PostgreSQL 18+ native
    email TEXT UNIQUE NOT NULL,
    created_at TIMESTAMPTZ DEFAULT NOW()
);

-- For PostgreSQL < 18, use custom function:
-- id UUID PRIMARY KEY DEFAULT uuid_generate_v7(),

-- ULID for human-readable IDs
CREATE TABLE orders (
    id TEXT PRIMARY KEY DEFAULT ulid_generate(),
    user_id UUID REFERENCES users(id),
    amount DECIMAL(10,2)
);

-- TypeID for type-safe multi-entity systems
CREATE TABLE entities (
    id TEXT PRIMARY KEY,
    entity_type TEXT NOT NULL,
    data JSONB
);

-- Insert with TypeID
INSERT INTO entities (id, entity_type, data)
VALUES (typeid_generate_text('product'), 'product', '{"name": "Widget"}');

Migration Strategy

-- Gradual migration from UUIDv4 to UUIDv7
-- PostgreSQL 18+: Use native function
ALTER TABLE existing_table ADD COLUMN new_id UUID DEFAULT uuidv7();

-- PostgreSQL < 18: Use custom function
-- ALTER TABLE existing_table ADD COLUMN new_id UUID DEFAULT uuid_generate_v7();

-- Backfill existing records (optional)
UPDATE existing_table SET new_id = uuidv7() WHERE new_id IS NULL;

-- Switch primary key
ALTER TABLE existing_table DROP CONSTRAINT existing_table_pkey;
ALTER TABLE existing_table ADD PRIMARY KEY (new_id);
ALTER TABLE existing_table DROP COLUMN id;
ALTER TABLE existing_table RENAME COLUMN new_id TO id;

Future Considerations

PostgreSQL 18 Improvements

PostgreSQL 18 provides significant advances:

• Native uuidv7(): C-level implementation with sub-millisecond precision
• Monotonicity: Guaranteed ordering within database sessions
• Built-in functions: uuid_extract_timestamp(), uuid_extract_version()
• Performance: Demonstrated parity with UUIDv4 (74.3 vs 71.6 μs) and throughput around 21.7K ops/sec
• Backward compatibility: Seamless replacement for custom functions

Performance Recommendations

Based on our benchmarks:

1. For PostgreSQL 18+ projects (when available): Use native uuidv7()
2. For existing systems: Custom UUIDv7 implementations remain excellent
3. For human-readable IDs: ULID provides best developer experience
4. For type safety: TypeID prevents costly ID-related bugs

Conclusion

Modern applications have excellent choices for time-ordered identifiers in PostgreSQL. Based on our comprehensive benchmarking:

Performance Summary

Latest Benchmark Results (10 runs × 100k iterations):

• UUIDv4 (gen_random_uuid, PG17): 71.4 μs avg, ~21.4K ops/sec (baseline fastest)
• UUIDv7 (uuidv7_custom, PG18): 71.8 μs avg, 21,688 ops/sec (fastest UUIDv7, ~0.6% off UUIDv4)
• UUIDv7 (uuid_generate_v7, PG18): 73.8 μs avg, 21,877 ops/sec (top UUIDv7 throughput on PG18)
• UUIDv7 (uuidv7_native, PG18): 74.3 μs avg, 21,674 ops/sec (native support with throughput parity)
• ULID (ulid_generate, PG17): 80.3 μs avg, 23,160 ops/sec (throughput leader when readability matters)
• TypeID (typeid_generate_text, PG18): 87.8 μs avg, 22,857 ops/sec (type-safe, slightly slower)

Decision Matrix

Key Findings

1. Native uuidv7() lands at UUIDv4 parity - 74.3 vs 71.6 μs with ~21.7K ops/sec
2. Fastest UUIDv7 - uuidv7_custom (PG18) at 71.8 μs, within 0.6% of UUIDv4
3. Throughput leader - ulid_generate (PG17) at 23,160 ops/sec; top UUIDv7 throughput is uuid_generate_v7 (PG18) at 21,877 ops/sec
4. Updated methodology - 10 runs × 100k iterations + concurrency (10×10k) with warmups
5. Zero collisions observed across 50,000+ generations per implementation
6. Storage efficiency varies by format: UUIDs (16 bytes binary) vs ULID (26 bytes text) vs TypeID (31+ bytes text)
7. Time-ordered identifiers are production-ready with negligible performance penalty

Decision Guide

Choose ID Generation Method
         ↓
  Primary Requirement?
         ↓
    ┌────┼────┬────────────────┬──────────────┐
    ↓         ↓                ↓              ↓
Maximum    Time           Human        Type
Concurrent Ordering      Readability   Safety
Performance   ↓              ↓          ↓
    ↓         ↓              ↓          ↓
🔴 UUIDv4   Need Sub-ms  🟠 ULID    🟣 TypeID
~21.6K      Precision?      Base32     Prefixed
ops/sec        ↓            encoded    identifiers
Battle-        ↓            Lexicographic Self-documenting
tested      ┌──┴──┐         sort
           Yes   No
            ↓     ↓
       PostgreSQL Performance
       Version?   Priority?
          ↓         ↓
       ┌──┴──┐  ┌──┴──┐
      18+   <18 Single- Balanced
       ↓     ↓  threaded Approach
   🟢 PostgreSQL 🟡 UUIDv7    ↓        ↓
   18 native     Sub-ms   🔵 UUIDv7  🟢 UUIDv7
   uuidv7        Custom    PL/pgSQL   Pure SQL
   C-level       precision 75.9 μs    No PL/pgSQL
   performance   Best time ~71.8–73 μs overhead
                 ordering  UUIDv4     Good all-around

Performance Summary

🏁 Performance Champions

• 🥇 Overall Latency: gen_random_uuid (PG17) → 71.4 μs; fastest UUIDv7 is uuidv7_custom (PG18) → 71.8 μs
• 🥇 Throughput: ulid_generate (PG17) → 23,160 ops/sec; top UUIDv7 throughput on PG18 is uuid_generate_v7 → 21,877 ops/sec
• 🥇 Storage Efficient: ULID → 26 bytes (Most compact text representation)

🎯 Specialized Features

• 👁️ Human Readable: ULID → Base32 encoding, no special characters
• 🛡️ Type Safe: TypeID → Prefixed identifiers, self-documenting
• ⏱️ Time Precision: UUIDv7 (Sub-ms) → Sub-millisecond, best ordering

🔮 Future Ready

• 🚀 PostgreSQL 18+: native uuidv7() → C-level implementation, GA with near-baseline latency

The modern identifier landscape offers powerful options beyond traditional UUIDs. Choose based on your application’s specific requirements for readability, type safety, storage efficiency, and compatibility needs.

Resources

• Benchmark Repository - Full benchmark code and results
• IETF UUIDv7 Draft - Official specification
• PostgreSQL UUID Functions - PostgreSQL documentation

Last updated: December 2025 | PostgreSQL 17 & 18 GA with latest 10×100k benchmark data