The same table, the same rows, about 1.5 times the disk. That was the measurement after someone made UUIDv4 the primary key in InnoDB, and that is before counting secondary indexes.
Every new API wants UUIDs. Distributed generation, no coordination, nothing leaks about row counts. All true. Then the database quietly starts paying.
InnoDB clusters the table by primary key. Auto-increment inserts always land in the rightmost page, warm and predictable. Random UUIDs land anywhere in the tree: page splits everywhere, half-empty pages, and the set of hot pages becomes the whole index. Secondary indexes store the primary key in every entry, so each of them inherits the full 16 bytes too. In PostgreSQL the heap does not cluster, so the pain is smaller, but index bloat and lost locality are still there.
The fix is not “bigint everywhere again”. It is time-ordered identifiers. ULID, or UUIDv7, which is going through the RFC process right now. The high bits are a timestamp, so new keys sort near each other and inserts stay local, while the id is still generated anywhere without coordination. Symfony’s uid component and Ramsey’s library both give you such ids today.
And a separate thought that removes half the debate. Public identifier and primary key do not have to be the same column. Internal bigint PK for joins and clustering, external ULID for URLs and API payloads, unique index on it. Sixteen bytes and one index. The argument about leaking sequence numbers and the argument about B-tree locality stop fighting, because they were never about the same column.
SHOW TABLE STATUS is where this decision actually lives. I did not open it until the table had already grown by half.