🔥 ULIDs: The Better Default for Modern Systems – Lessons from Shopify

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

Identifiers in distributed systems impact performance, scalability, and observability. For years, UUIDs (Universally Unique Identifiers) have been the go-to choice, but as Shopify discovered while optimizing their payment infrastructure, UUIDs come with limitations. Their solution? ULIDs (Universally Unique Lexicographically Sortable Identifiers).

The Problem with UUIDs

UUIDs, especially UUIDv4, introduce challenges in high-scale environments:

1. Database Performance Issues – UUIDs are randomly distributed, causing index fragmentation and frequent page splits in databases like MySQL. These inefficiencies lead to slower insert operations and increased storage overhead, which can severely impact high-throughput systems.
2. Operational Complexity – UUIDs lack embedded metadata, requiring extra queries to determine creation time. This adds unnecessary complexity when debugging system behavior or tracking event sequences.
3. Poor Readability and Usability – UUIDs are long, opaque, and hard to work with manually, making them less user-friendly for operations teams and debugging scenarios.

Why ULIDs are the Better Choice

ULIDs solve these problems by introducing lexicographic sortability while maintaining global uniqueness.

Key benefits:
✅ 50% Faster Database Inserts – Sequential ordering prevents index fragmentation, leading to more efficient B-tree indexing and significantly lower database maintenance overhead.
✅ Simplified Debugging – Timestamps in ULIDs provide instant context without extra joins, making it easier to track transactions and system events without additional metadata.
✅ Reduced Storage Overhead – No need for separate timestamp columns, which simplifies database schemas and reduces redundant data storage.
✅ Better Human Readability – Unlike UUIDs, ULIDs offer a more structured format that allows engineers and operators to quickly determine chronological relationships.

Shopify’s Experience

Shopify initially used UUIDv4 for idempotency keys in their payment system. However, as transaction volumes grew, database performance bottlenecks became more evident. The switch to ULIDs resulted in faster inserts, improved query performance, and simpler debugging. By aligning identifier generation with database-friendly structures, ULIDs optimized write-heavy workloads and improved system resilience. Additionally, engineers found incident response and observability improved, as the inherent timestamp structure of ULIDs reduced reliance on additional logging mechanisms.

Practical Considerations for Adopting ULIDs

If you’re considering switching to ULIDs, here are some key best practices:

• Store ULIDs as Binary – Rather than storing them as strings, using binary format can further optimize space and lookup speeds.
• Use Indexed ULIDs for Sorting – Taking advantage of their natural sortability can enhance performance for time-series data and event logging.
• Plan for Incremental Migration – If your system already uses UUIDs, consider gradually introducing ULIDs in new features rather than forcing a full migration.

When to Use ULIDs (and When Not To)

ULIDs are a superior default for most applications, from payment processing to event logging. However, UUIDs may still be preferable in cases requiring timestamp obfuscation (e.g., anonymized user tracking) or legacy system compatibility, where existing infrastructure is deeply integrated with UUID-based systems.

For a deeper dive into Shopify’s journey and technical insights, check out the full article here: ULIDs as the Default Choice for Modern Systems.

What are your thoughts? Have you migrated to ULIDs in your systems? Let’s discuss! 🚀

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