Pembuat UUID

UUID v4 (Random) Structure

UUID v7 (Time-ordered) Structure

Sequence Counter & Ordering

Perfect Use Cases

• • Database primary keys: Distributed systems, avoid auto-increment conflicts
• • API identifiers: Public-facing IDs that don't reveal record counts
• • Session tokens: User sessions, temporary authentication (v4 preferred)
• • File naming: Unique filenames, document versioning, media uploads
• • Microservices: Request tracing, correlation IDs, service communication
• • Event sourcing: Event IDs, command tracking (v7 for chronological order)
• • Cache keys: Distributed caching, temporary resource identification
• • Testing data: Reproducible test fixtures, mock data generation

Best Practices

• • Version choice: v4 for security/privacy, v7 for performance/ordering
• • Database storage: Use BINARY(16) or native UUID types, not VARCHAR
• • Indexing strategy: Clustered indexes work better with v7 than v4
• • Format consistency: Standardize on dashed/compact across your system
• • Case sensitivity: Choose uppercase or lowercase consistently
• • Validation: Always validate UUID format at API boundaries
• • Privacy consideration: v7 leaks creation time, use v4 for sensitive data
• • Performance: Generate UUIDs client-side to reduce server load

What's the difference between UUID versions?

Version 4 is randomly generated and most common for general use. Version 7 includes timestamp for natural sorting while maintaining randomness. V4 is perfect for general purposes, while V7 is ideal when you need chronological ordering or time-based partitioning.

When should I use UUID v7 over v4?

Use UUID v7 when you need time-ordered identifiers for better database performance, natural sorting, or time-based partitioning. V7 UUIDs sort chronologically and can improve INSERT performance in databases. Use v4 when you need maximum randomness and don't care about ordering.

How does UUID v7 maintain uniqueness while being time-ordered?

UUID v7 uses a 48-bit timestamp (milliseconds since Unix epoch), a 12-bit sequence counter, and 62 bits of random data. This ensures chronological ordering while maintaining extremely low collision probability. The timestamp portion allows natural sorting, the sequence counter handles multiple UUIDs within the same millisecond, and the random suffix prevents conflicts.

What are the benefits of UUID v7 for databases?

UUID v7 improves database performance by reducing index fragmentation since new records are inserted in chronological order. This leads to better INSERT performance, more efficient range queries, and improved cache locality. It's particularly beneficial for time-series data and audit logs.

Are UUIDs truly unique across all systems?

Version 4 UUIDs have a collision probability so low (1 in 5.3x10^36) that they're considered practically unique. The chance of generating a duplicate is negligible even across billions of systems generating millions of UUIDs per second.

Should I use UUIDs or auto-incrementing integers?

Use UUIDs when you need distributed systems compatibility, want to avoid exposing record counts, or need offline generation. Use integers for better performance, smaller storage, and when you need sequential ordering. UUIDs are better for APIs and microservices.

What's the performance impact of using UUIDs?

UUIDs are larger (128 bits vs 32/64 bits for integers) and slower to index. However, the performance difference is usually negligible for most applications. Store as binary rather than strings in databases for better performance and consider clustered indexes.

Can I use UUIDs for security purposes?

UUIDs provide obscurity but aren't cryptographically secure. Don't rely on them for authentication tokens or security-critical applications. Use proper cryptographic methods for security. UUIDs are good for preventing enumeration attacks on public IDs.

How do I store UUIDs efficiently in databases?

Store as BINARY(16) or UUID native types rather than VARCHAR(36) to save space and improve performance. Use proper indexing strategies and consider partitioning for very large tables. Some databases have specific UUID functions for optimal handling.

What's the difference between UUID v1, v4, and v7?

UUID v1 uses MAC address and timestamp (privacy concerns), v4 is purely random (most common), and v7 uses timestamp with random suffix (newest, best for databases). v4 is recommended for general use, v7 for time-ordered applications.

Can UUID v7 reveal sensitive timing information?

Yes, UUID v7 contains a millisecond-precision timestamp that reveals when it was generated. This could be a privacy concern for sensitive applications. Use UUID v4 when creation time should remain private.

How many UUIDs can I generate per second with v7?

UUID v7 can generate up to 4,096 unique UUIDs per millisecond (due to the 12-bit sequence counter), which equals over 4 million UUIDs per second. When the counter overflows, the timestamp advances to maintain uniqueness.