Let’s explore how to use UUID as a primary key in PostgreSQL. While UUIDs are easy to generate, share across distributed systems, and ensure uniqueness, they raise concerns regarding size and performance. This article discusses efficient methods for using UUID as a primary key in PostgreSQL, particularly optimizing performance with UUID v7.
![](/wp-resource/resources/articles/2024/07/postgresql-uuid-primary-key-efficient-use-01.png)
What is a UUID?
UUID (Universally Unique Identifier) is a method of generating unique identifiers and is frequently used as a primary key in database tables. It can be easily shared across distributed systems and ensures uniqueness. However, since a UUID is 128 bits in size, its suitability as a primary key may be questioned. Despite this, many situations leave no alternative.
Using UUID Data Type in PostgreSQL
PostgreSQL provides a dedicated `uuid` data type to store UUIDs. This 128-bit data type requires 16 bytes to store a single value. While you could store it as text using the text type, it is not suitable for UUID storage. Experiments show that tables using the text type are 54% larger, and index sizes are 85% larger compared to those using the UUID type.
Relationship Between UUID and B-Tree Index
B-Tree indexes work well with ordered values, but random UUIDs are not suitable for B-Tree indexes. Java’s `UUID.randomUUID()` returns a UUID v4, which is pseudo-random. Conversely, UUID v7 generates time-ordered values, making it suitable for B-Tree indexes and improving insert performance.
Using UUID v7
To use UUID v7 in Java, the `java-uuid-generator` library is required. Generating UUID v7 can result in roughly double the insert performance. Experiments show that tables using UUID v7 have about twice the performance improvement compared to those using UUID v4 when inserting 10,000 rows ten times.
Need for Optimization
If you expect large datasets or high traffic, optimization is necessary. Changing the primary key later is challenging, so it’s crucial to set it correctly from the start. Even with optimization, UUID might not be the optimal type as a primary key. If possible, consider alternatives like TSID.
Conclusion
Using UUID as a primary key offers many advantages, but performance optimization is necessary. Employing UUID v7 can significantly enhance insert performance, making efficient use of UUID in PostgreSQL essential. For large datasets or expected high traffic, setting things up correctly from the beginning is vital.
Database optimization in PostgreSQL is crucial for maximizing your system’s performance. Start using UUID v7 now to boost performance.
Reference: Maciej Walkowiak