@@ -113,6 +113,8 @@ sortable (like :ref:`ULIDs <ulid>`). It's more efficient for database indexing
113
113
It's recommended to use UUIDv7 instead of UUIDv6 because it provides
114
114
better entropy.
115
115
116
+ .. _uid-uuid-v7 :
117
+
116
118
**UUID v7 ** (UNIX timestamp)
117
119
118
120
Generates time-ordered UUIDs based on a high-resolution Unix Epoch timestamp
@@ -357,6 +359,14 @@ entity primary keys::
357
359
// ...
358
360
}
359
361
362
+ .. caution ::
363
+
364
+ Using UUIDs as primary keys is usually not recommended for performance reasons:
365
+ indexes are slower and take more space (because UUIDs in binary format take
366
+ 128 bits instead of 32/64 bits for auto-incremental integers) and the non-sequential
367
+ nature of UUIDs fragments indexes. :ref: `UUID v7 <uid-uuid-v7 >` is the only
368
+ variant that solves the fragmentation issue (but the index size issue remains).
369
+
360
370
When using built-in Doctrine repository methods (e.g. ``findOneBy() ``), Doctrine
361
371
knows how to convert these UUID types to build the SQL query
362
372
(e.g. ``->findOneBy(['user' => $user->getUuid()]) ``). However, when using DQL
@@ -535,9 +545,15 @@ entity primary keys::
535
545
}
536
546
537
547
// ...
538
-
539
548
}
540
549
550
+ .. caution ::
551
+
552
+ Using ULIDs as primary keys is usually not recommended for performance reasons.
553
+ Although ULIDs don't suffer from index fragmentation issues (because the values
554
+ are sequential), their indexes are slower and take more space (because ULIDs
555
+ in binary format take 128 bits instead of 32/64 bits for auto-incremental integers).
556
+
541
557
When using built-in Doctrine repository methods (e.g. ``findOneBy() ``), Doctrine
542
558
knows how to convert these ULID types to build the SQL query
543
559
(e.g. ``->findOneBy(['user' => $user->getUlid()]) ``). However, when using DQL
0 commit comments