Skip to content

Commit 58246ac

Browse files
committed
Also mention ULIDs
1 parent 0b8b95f commit 58246ac

File tree

1 file changed

+9
-3
lines changed

1 file changed

+9
-3
lines changed

components/uid.rst

Lines changed: 9 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -347,8 +347,8 @@ entity primary keys::
347347
.. caution::
348348

349349
Using UUIDs as primary keys is usually not recommended for performance reasons:
350-
indexes take more space (because UUIDs in binary format take 128 bits instead
351-
of 32/64 bits for auto-incremental integers) and the non-sequential nature of
350+
indexes are slower and take more space (because UUIDs in binary format take 128 bits
351+
instead of 32/64 bits for auto-incremental integers) and the non-sequential nature of
352352
UUIDs fragments indexes. UUID v7 is the only variant that solves the fragmentation
353353
issue (but the index size issue remains).
354354

@@ -538,9 +538,15 @@ entity primary keys::
538538
}
539539

540540
// ...
541-
542541
}
543542

543+
.. caution::
544+
545+
Using ULIDs as primary keys is usually not recommended for performance reasons.
546+
Although ULIDs don't suffer from index fragmentation issues (because the values
547+
are sequential), their indexes are slower and take more space (because ULIDs
548+
in binary format take 128 bits instead of 32/64 bits for auto-incremental integers).
549+
544550
When using built-in Doctrine repository methods (e.g. ``findOneBy()``), Doctrine
545551
knows how to convert these ULID types to build the SQL query
546552
(e.g. ``->findOneBy(['user' => $user->getUlid()])``). However, when using DQL

0 commit comments

Comments
 (0)