Quick recommendation: For the safest, standards-based choice, use
GUID / UUID v4 (fully random) or
GUID / UUID v7 (time-ordered for databases). Consider
XID when you need compact, sortable IDs for distributed systems and value storage efficiency.
XID - Globally unique ID generator library - github.com
Overview
XID is a globally unique identifier generator created as a compact alternative to UUID for distributed systems. Unlike standard GUIDs / UUIDs (128 bits), XID generates 96-bit identifiers that are time-ordered, machine-aware, and encoded in a compact 20-character Base32 format.
When choosing an identifier for your application or database schema, you're usually deciding between standard GUIDs / UUIDs (governed by RFC 9562) and XID, a non-standard but efficient identifier format designed for distributed applications.
Comparison table
| Property | GUID / UUID v4 | GUID / UUID v7 | XID |
|---|
| Size | 128-bit (16 bytes) | 128-bit (16 bytes) | 96-bit (12 bytes) |
|---|
| Encoding | Hex (8-4-4-4-12) | Hex (8-4-4-4-12) | Base32 (Crockford) |
|---|
| String length | 36 characters | 36 characters | 20 characters |
|---|
| Time-sortable | No | Yes (millisecond) | Yes (second precision) |
|---|
| Standard | RFC 4122 and RFC 9562 | RFC 4122 and RFC 9562 | No RFC |
|---|
| Human-readable | Moderate
Hex with hyphens | Moderate
Hex with hyphens | Good
Base32, case-insensitive |
|---|
| URL-safe | Needs escaping (hyphens OK) | Needs escaping (hyphens OK) | Yes (Base32) |
|---|
| Database-friendly | Excellent
Native UUID support | Excellent
Native support + sortable | Good
Stored as BINARY(12) or VARCHAR(20) |
|---|
| Collision resistant | Excellent
122 bits random | Excellent
74 bits random | Good
40 bits random + machine ID |
|---|
| Generation speed | Fast | Fast | Very fast
No cryptographic randomness |
|---|
| Best for | General-purpose IDs, privacy-friendly identifiers and fully random | Database primary keys, event ordering, time-correlated IDs | Compact sortable IDs, distributed systems, storage-constrained environments |
|---|
Detailed comparison
Structure: 128 bits with 122 bits of randomness. No timestamp information.
- Pros: Universally supported, RFC standard, no time leakage, simple generation and native database support
- Cons: Random insertion pattern can cause index fragmentation, larger storage (16 bytes)
- Use when: You want maximum compatibility and don't need time-ordering
Example: 550e8400-e29b-41d4-a716-446655440000
Structure: 128 bits with 48-bit Unix millisecond timestamp prefix + 74 bits randomness.
- Pros: RFC standard, time-ordered (millisecond precision), database-friendly, widely supported and no coordination needed
- Cons: Reveals creation timestamp, larger storage (16 bytes)
- Use when: You want time-ordering with RFC compliance for database primary keys
Example: 018f3f5e-1c2d-7a9b-8f10-3c4d5e6f7a8b
XID
Structure: 96 bits (12 bytes) with 32-bit Unix timestamp (second precision) + 24-bit machine ID + 16-bit process ID + 24-bit counter.
- Pros: Compact (12 bytes vs UUID's 16), time-sortable, URL-safe Base32 encoding, very fast generation, and no cryptographic overhead
- Cons: Not RFC standard, lower collision resistance (40 bits random vs UUID's 74+), second precision only, and reveals machine/process information
- Use when: You need compact, sortable IDs for distributed systems and prioritize storage efficiency
Example: 9m4e2mr0ui3e8a215n4g
Which one should you use?
- Choose GUID / UUID v4 if you want the safest default: universally supported, RFC standard, native database types and works across all languages and platforms.
- Choose GUID / UUID v7 if you want a standards-based ID that is time-ordered with millisecond precision for better database index performance.
- Choose XID if you need compact (12 bytes), sortable IDs for distributed systems, value storage efficiency over RFC compliance, and can accept second-precision time-ordering.
XID structure breakdown
XID's 96-bit (12-byte) structure is composed of:
- 4 bytes (32 bits): Unix timestamp in seconds (not milliseconds)
- 3 bytes (24 bits): Machine identifier (derived from hostname)
- 2 bytes (16 bits): Process ID
- 3 bytes (24 bits): Random counter initialized at process start
This structure ensures IDs are sortable by time and unique across different machines and processes in a distributed system.
Practical guidance for distributed systems
XID is designed for efficiency in distributed systems:
- Compact storage: 25% smaller than UUID (12 bytes vs 16 bytes)
- Time-ordering: Second-precision timestamp prefix ensures chronological sorting
- Machine-aware: Includes machine and process identifiers to prevent collisions
- Fast generation: No cryptographic operations makes it very fast
Performance considerations
- Generation speed: XID is extremely fast (no cryptographic randomness required)
- Storage efficiency: 12 bytes vs UUID's 16 bytes = 25% storage savings
- String representation: 20 characters (Base32) vs UUID's 36 (hex with hyphens)
- Database indexes: Time-ordering improves B-tree index insert performance
- Time precision: Second-level vs UUID v7's millisecond-level precision
Collision resistance
XID's collision resistance comes from multiple sources:
- Timestamp: Different seconds produce different IDs
- Machine ID: Different machines have different IDs
- Process ID: Different processes on same machine have different IDs
- Counter: 24-bit counter (16.7 million IDs per second per process)
However, with only 40 bits of true randomness (counter initialization), XID has lower collision resistance than UUID v4 (122 bits) or UUID v7 (74 bits) when considering truly random collisions.
Interoperability and ecosystem support
GUID / UUID has the broadest support across programming languages, databases, and frameworks:
- Databases: Native GUID / UUID types in PostgreSQL, MySQL, SQL Server, Oracle, etc.
- Languages: Built-in support in Java, C#, Python, Go, Ruby, JavaScript, and many more
- APIs: JSON, REST, GraphQL commonly use GUID / UUID for resource identifiers
XID has more limited but growing support:
- Go: Original implementation and excellent support
- Other languages: Ports available for JavaScript, Python, Java, Rust, and more
- Databases: Stored as BINARY(12) or VARCHAR(20) (no native XID type)
- Ecosystem: Smaller ecosystem compared to UUID but active community
Base32 encoding (Crockford)
XID uses Crockford Base32 encoding which offers several advantages:
- URL-safe: No special characters that need escaping in URLs
- Case-insensitive: Can be lowercased for storage and comparison
- Human-friendly: Excludes ambiguous characters (0/O, 1/I/L)
- Compact: More efficient than hex encoding
Other identifier formats
Beyond GUIDs / UUIDs and XID, there are many other identifier formats each with their own trade-offs. For a comprehensive comparison of all popular identifier formats, see our complete identifier comparison guide.
For most applications requiring broad compatibility and standards compliance, standard GUIDs / UUIDs remain the recommended choice.
Warnings and trade-offs
- Not RFC standard: XID is not governed by an RFC like UUIDs, which may matter for systems requiring strict standards compliance
- Lower collision resistance: With 40 bits of randomness vs UUID's 74-122 bits, XID has higher theoretical collision risk
- Time precision: Second-level precision vs UUID v7's millisecond precision may not be sufficient for high-frequency event ordering
- Information leakage: Reveals timestamp, machine, and process information which may matter for privacy-sensitive applications
- Database support: No native XID database type - must be stored as BINARY or VARCHAR
- Limited ecosystem: Less mature ecosystem compared to UUID with fewer tools and integrations
Frequently Asked Questions
No. XID is 96 bits (12 bytes) while UUID is 128 bits (16 bytes). It's not governed by
RFC 9562 and uses a different structure and encoding. If you need a standards-based GUID / UUID, use
v4 or
v7.
Storage efficiency. XID prioritizes compactness with 12 bytes instead of UUID's 16 bytes (25% smaller). This reduces storage, memory, and bandwidth at the cost of lower collision resistance. For most distributed systems, 96 bits with timestamp + machine + process + counter provides sufficient uniqueness.
Yes. XID works well as a primary key stored as BINARY(12) or VARCHAR(20). The time-ordering provides good index locality. However,
UUID v7 is generally better for database primary keys due to native database support, standards compliance, and millisecond precision.
Very similar. Both are 12 bytes with timestamp + machine + process + counter structure. The main difference is encoding: MongoDB ObjectId uses hexadecimal (24 characters) while XID uses Base32 (20 characters). XID's Base32 encoding is more compact and URL-safe.
For identifiers, yes (not secrets). XID provides sufficient uniqueness for distributed ID generation. However, it has lower randomness than UUIDs and reveals timestamp, machine, and process information. Like all identifiers, XID should not be used as passwords, access tokens, or cryptographic secrets.
XID's collision resistance comes from timestamp + machine ID + process ID + counter. Within a single second on the same process, the 24-bit counter allows 16.7 million unique IDs. Across different machines, processes, or seconds, collisions are extremely unlikely. However, with 40 bits of true randomness, it's less resistant to random collisions than UUID v4 (122 bits).
No. XID is 96 bits while UUID is 128 bits. They have completely different structures and cannot be losslessly converted. If you need to use both in the same system, store them separately or choose one format and stick with it consistently.
Choose based on event frequency. XID's second precision is sufficient for most applications. Choose
UUID v7 with millisecond precision when you need to order high-frequency events (thousands per second) or require finer-grained time resolution.
Choose
UUID v7 when you need RFC standard compliance, native database UUID type support, millisecond precision, higher collision resistance, or work in enterprise environments requiring standards-based identifiers. Choose XID when storage efficiency (25% smaller) outweighs these benefits.
Conclusion
For broad interoperability and standards compliance, choose a standard GUID / UUID: v4 for general-purpose fully random IDs or v7 for time-ordered database-friendly identifiers with millisecond precision.
Choose XID when you need compact (12 bytes), time-sortable identifiers for distributed systems, prioritize storage efficiency over RFC compliance, and can accept second-precision time-ordering. XID is particularly well-suited for storage-constrained environments and systems inspired by MongoDB's ObjectId design.