Quick recommendation: For the safest, standards-based choice, use
GUID / UUID v4 (fully random) or
GUID / UUID v7 (time-ordered for databases). Consider
Cuid2 when you need sortable, collision-resistant IDs for horizontal scaling and don't require RFC compliance.
Cuid2 - Secure, collision-resistant IDs optimized for horizontal scaling - github.com
Cuid - Collision-resistant IDs optimized for horizontal scaling and binary search lookup performance - github.com (deprecated in favor of Cuid2)
Overview
Cuid was created by Eric Elliott as a collision-resistant unique identifier designed for distributed systems and horizontal scaling. The original Cuid has been succeeded by Cuid2, which addresses security concerns and improves collision resistance. Unlike standard GUIDs / UUIDs (128 bits), Cuid2 generates variable-length strings optimized for both sortability and security.
When choosing an identifier for your application or database schema, you're usually deciding between standard GUIDs / UUIDs (governed by RFC 9562) and Cuid2, a non-standard but modern identifier format designed for distributed applications.
Comparison table
| Property | GUID / UUID v4 | GUID / UUID v7 | Cuid2 |
|---|
| Size | 128-bit | 128-bit | Variable (default 24 chars ≈ 144 bits entropy) |
|---|
| Encoding | Hex (8-4-4-4-12) | Hex (8-4-4-4-12) | Base36 lowercase (a-z0-9) |
|---|
| String length | 36 characters | 36 characters | 24 characters (default, customizable) |
|---|
| Time-sortable | No | Yes (millisecond) | Yes (millisecond) |
|---|
| Standard | RFC 4122 and RFC 9562 | RFC 4122 and RFC 9562 | No RFC |
|---|
| Human-readable | Moderate
Hex with hyphens | Moderate
Hex with hyphens | Good
Lowercase alphanumeric |
|---|
| URL-safe | Needs escaping (hyphens OK) | Needs escaping (hyphens OK) | Yes (a-z0-9) |
|---|
| Database-friendly | Excellent
Native UUID support | Excellent
Native support + sortable | Good
Stored as VARCHAR, sortable |
|---|
| Collision resistant | Excellent
122 bits random | Excellent
74 bits random | Excellent
~144 bits entropy default |
|---|
| Best for | General-purpose IDs, privacy-friendly identifiers and fully random | Database primary keys, event ordering, time-correlated IDs | Distributed systems, horizontal scaling, sortable user-facing IDs |
|---|
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, not time-sortable
- 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, database-friendly, widely supported and no coordination needed
- Cons: Reveals creation timestamp (millisecond precision)
- Use when: You want time-ordering with RFC compliance for database primary keys
Example: 018f3f5e-1c2d-7a9b-8f10-3c4d5e6f7a8b
Cuid2
Structure: Variable-length string (default 24 characters) with timestamp prefix, session counter, host fingerprint, and random data encoded in Base36.
- Pros: Time-sortable, highly collision-resistant, URL-safe, case-insensitive, customizable length and designed for distributed systems
- Cons: Not an RFC standard, no native database type, reveals creation timestamp, and larger than UUID (24 vs 36 chars string)
- Use when: You need sortable, collision-resistant IDs for distributed systems and don't require RFC compliance
Example: ckr3q4z5x0000j8dg2p8h9q3k
Cuid vs Cuid2
The original Cuid has been deprecated in favor of Cuid2 due to security and collision concerns:
- Cuid (deprecated): 25 characters, predictable structure, weaker collision resistance and security vulnerabilities identified
- Cuid2 (current): Default 24 characters, improved randomness, stronger collision resistance, addresses security concerns and better entropy distribution
Recommendation: Always use Cuid2, not the original Cuid. The original has known weaknesses and is no longer maintained.
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 for better database index performance with RFC compliance.
- Choose Cuid2 if you need time-sortable, collision-resistant IDs for distributed systems, value case-insensitivity and URL-safety, and don't require RFC standards compliance.
Practical guidance for distributed systems
Cuid2 was specifically designed for distributed systems and horizontal scaling:
- Collision resistance: Extremely low collision probability even in distributed environments
- Time-ordering: Prefix with timestamp ensures chronological sorting
- Session-based counter: Helps prevent collisions within the same process
- Host fingerprint: Reduces collision risk across different machines
Performance considerations
- Generation speed: Cuid2 is fast but slightly slower than simple random generators due to additional entropy sources
- String length: 24 characters (default) is shorter than UUID's 36 but longer than NanoID's 21
- Database indexes: Time-ordering improves insert performance in B-tree indexes similar to UUID v7
- Case-insensitive: Uses only lowercase letters (a-z) and digits (0-9) for easier handling
Security considerations
Cuid2 addressed security issues found in the original Cuid:
- Improved randomness: Uses cryptographically strong random sources
- Better entropy distribution: Reduces predictability compared to Cuid
- No sequential patterns: Harder to predict next ID compared to simple timestamp-based systems
- Not a security token: Like all identifiers, Cuid2 should not be used as passwords or secrets
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
Cuid2 has growing but more limited support:
- JavaScript/TypeScript: Official implementation available
- Databases: Stored as VARCHAR/TEXT (no native Cuid type)
- Other languages: Community implementations exist for several languages but not standardized
- Ecosystem maturity: Newer format with less widespread adoption than UUID
Cuid2 customization
Cuid2 offers customization options:
- Length: Adjustable length (default 24 characters) to balance uniqueness vs brevity
- Fingerprint: Custom host fingerprint can be provided for specific deployment scenarios
- Trade-offs: Shorter lengths reduce collision resistance; use defaults unless you have specific requirements
Other identifier formats
Beyond GUIDs / UUIDs and Cuid2, 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: Cuid2 is not governed by an RFC like UUIDs, which may matter for systems requiring strict standards compliance
- Database support: No native database type for Cuid2 - stored as VARCHAR/TEXT which can be less efficient than native UUID types
- Ecosystem maturity: Less mature than UUID with fewer libraries, tools, and integrations
- Time leakage: Reveals approximate creation time like UUID v7, which may matter for privacy-sensitive applications
- Migration from Cuid: If upgrading from original Cuid, requires careful migration planning
- String length: While shorter than UUID (24 vs 36 chars), still longer than some alternatives like NanoID
Frequently Asked Questions
No. Cuid2 is a completely different identifier format. 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.
Both are time-sortable, but they have different trade-offs. UUID v7 is an RFC standard with broad database support and universal adoption. Cuid2 is shorter (24 vs 36 chars), URL-safe, case-insensitive, and includes additional entropy sources for distributed systems. Choose UUID v7 for standards compliance and broad support; choose Cuid2 for URL-friendliness and distributed system optimization.
Yes, if possible. The original Cuid has known security and collision resistance issues and has been deprecated by its creator. Cuid2 addresses these problems with improved randomness and entropy distribution. For new projects, always use Cuid2. For existing systems, plan a migration when feasible, especially if security or collision resistance is critical.
Yes, stored as VARCHAR. You can use Cuid2 as a primary key stored as VARCHAR(24) or similar. The time-ordering provides good index locality. However,
UUID v7 is generally better for database primary keys due to native database support and standards compliance.
Yes, for identifiers (not secrets). Cuid2 uses cryptographically strong random sources and has excellent collision resistance. However, like all identifiers, Cuid2 should not be used as passwords, access tokens, or cryptographic secrets. It's an identifier, not a security token.
With default settings (24 characters), Cuid2 provides approximately 144 bits of entropy, which is higher than UUID v4's 122 bits. This makes it extremely collision-resistant even in large distributed systems generating billions of IDs. The combination of timestamp, session counter, host fingerprint, and random data provides excellent collision resistance.
No. Cuid2 and UUID have completely different structures and formats. There's no lossless conversion between them. If you need to use both in the same system, store them separately or choose one format and stick with it consistently.
No. Cuid2 uses only lowercase letters (a-z) and digits (0-9) in its Base36 encoding, making it inherently case-insensitive. This is an advantage over formats that mix upper and lowercase, as it reduces user errors and simplifies handling in case-insensitive systems.
Choose
UUID v7 when you need RFC standard compliance, native database UUID type support, cross-platform compatibility, and work in enterprise environments. Choose Cuid2 when you need URL-safe, case-insensitive, sortable IDs optimized for distributed systems and don't require RFC compliance.
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.
Choose Cuid2 when you need time-sortable, collision-resistant identifiers for distributed systems, value URL-safety and case-insensitivity, and don't require RFC standards compliance or native database UUID types. Cuid2 is particularly well-suited for horizontal scaling scenarios and web applications where URL-friendliness matters.