4 ms·

>Use 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

by gruez 2y ago

>Use 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.

TylerE 2y ago
The concern isn’t the sign of the db on disc but doubling the size of all the indexes in memory
- sgarland 2y ago
  Or if it’s MySQL, the PK is implicitly copied into every secondary index. Adds up quickly.
  - pyuser583 2y ago
    Wow did not know that. MySQL has tons of hidden behavior.
    - sgarland 2y ago
      So does Postgres to an extent, but in general, MySQL has more hidden edge cases, and Postgres has more hidden maintenance requirements.
sgarland 2y ago
When you have a few million rows, no. When you have hundreds of millions or billions of rows, yes, it matters very much.
- LunaSea 2y ago
  In many-to-many tables, the per-row overhead of the DBM usually weighs much more than the actual column data.