Comment on My takeaways from DjangoCon EU 2025parentComments−gruez1yUse bigint, never UUID. UUIDs are massive (2x a bigint) and now your DBMS has to copy that enormous value to every side of a relation."enormous value" = 128 bits (compared to 64 bits)In the worst case this causes your m2m table to double, but I doubt this has a significant impact on the overall size of the DB.−TylerE1yThe concern isn’t the sign of the db on disc but doubling the size of all the indexes in memory−sgarland1yOr if it’s MySQL, the PK is implicitly copied into every secondary index. Adds up quickly.−pyuser5831yWow did not know that. MySQL has tons of hidden behavior.−sgarland1ySo does Postgres to an extent, but in general, MySQL has more hidden edge cases, and Postgres has more hidden maintenance requirements.−sgarland1yWhen you have a few million rows, no. When you have hundreds of millions or billions of rows, yes, it matters very much.−LunaSea1yIn many-to-many tables, the per-row overhead of the DBM usually weighs much more than the actual column data.
Comments
"enormous value" = 128 bits (compared to 64 bits)
In the worst case this causes your m2m table to double, but I doubt this has a significant impact on the overall size of the DB.
The concern isn’t the sign of the db on disc but doubling the size of all the indexes in memory
Or if it’s MySQL, the PK is implicitly copied into every secondary index. Adds up quickly.
Wow did not know that. MySQL has tons of hidden behavior.
So does Postgres to an extent, but in general, MySQL has more hidden edge cases, and Postgres has more hidden maintenance requirements.
When you have a few million rows, no. When you have hundreds of millions or billions of rows, yes, it matters very much.
In many-to-many tables, the per-row overhead of the DBM usually weighs much more than the actual column data.