UUID vs ULID vs Integer IDs: A Technical Guide for Modern Systems

Question

Unique identifiers are the backbone of data management, distributed systems, and secure API design. While UUIDs (UUIDv4) and integer IDs are widely used, ULIDs (Universally Unique Lexicographically Sortable Identifiers) are emerging as a superior choice for modern applications. This article explores their technical differences, focusing on performance in .NET ecosystems and database-level implications.

This article was originally published on the ByteAether Blog. It has been republished here with minor edits for clarity and conciseness.

Identifier Types

Integer IDs

Sequential numeric values managed by databases via auto-increment. Pros: simple, efficient for indexing. Cons: predictable (security risks), centralized generation (not ideal for distributed systems).

UUIDs

128-bit identifiers using randomness (UUIDv4). Pros: globally unique. Cons: lack sortability, cause database fragmentation (random insertion disrupts B+ tree indexes).

ULIDs

128-bit identifiers with a 48-bit timestamp (millisecond precision) and 80 bits of randomness. Pros: lexicographically sortable, compact, URL-safe, chronological insertion (reduces fragmentation).

Performance in .NET Applications

ULID Generation

The ByteAether.Ulid library generates ULIDs with zero heap allocations, leveraging stack-based operations. Key feature: monotonicity (sequential generation within the same millisecond), ensuring logical order in databases.

UUID Limitations

Guid.NewGuid() in .NET is fast but lacks ordering, causing random insertions and fragmentation. ULIDs align with database indexing patterns, improving throughput.

Database Performance: Index Fragmentation

Databases use B+ trees to store records in fixed-size pages. Random identifiers (UUIDs) force page splits, increasing I/O overhead, memory pressure, and write amplification. ULIDs embed timestamps, enabling sequential insertion and minimizing splits.

Implementing ULIDs in .NET

Entity Framework Core

public class Order  
{  
    public Ulid Id { get; set; } // Stored as BINARY(16)  
    public string Product { get; set; }  
}  

public class UlidToBytesConverter : ValueConverter<Ulid, byte[]>  
{  
    public UlidToBytesConverter() : base(
        x => x.ToByteArray(), x => Ulid.New(x)
    ) { }  
}

Dapper

public class UlidTypeHandler : SqlMapper.TypeHandler<Ulid>  
{  
    public override void SetValue(IDbDataParameter parameter, Ulid value)
        => parameter.Value = value.ToByteArray();  
    public override Ulid Parse(object value)
        => Ulid.New((byte[])value);  
}  

When to Use ULIDs

• Distributed Systems: Decentralized generation.
• Time-Series Data: Built-in timestamps simplify queries.
• Batch Processing: Monotonicity preserves order.

Why ByteAether.Ulid?

• Speed: Faster than other ULID implementations.
• Efficiency: Zero heap allocations.
• Integration: Works seamlessly with EF Core, Dapper, and JSON serializers.

Conclusion

ULIDs address the limitations of UUIDs and integers, offering sortability, reduced fragmentation, and scalability. For .NET developers, ByteAether.Ulid provides a future-proof solution.

Read the full guide: UUID vs ULID vs Integer IDs: A Technical Guide for Modern Systems

Install the library:

dotnet add package ByteAether.Ulid  

By adopting ULIDs, you can achieve faster queries, lower infrastructure costs, and scalable architectures.

This article was originally published on the ByteAether Blog. It has been republished here with minor edits for clarity and conciseness.