Use UUIDs in all the tables

Rolling IDs are considered to be a bad practice. There are (at least) few reasons for this:

• They are a security issue. From rolling numbers a malicious party can interpret information that the merchant does not want to share. Like user counts, order counts and such. If using UUIDs, a malicious party could not sniff this kind of information.
• Rolling numbers are problematic in distributed systems. If the database goes down, and the admin needs to restore the database from db dumb, some other system might have id number 42 pointing to a row in the database in Vendure. However, this row (let’s say user) no longer exist since the database dumb is 12 hours old. Now when the next user is created, some other system points to a wrong user and we might leak data from different user to another. Not good. When using UUIDs instead of rolling numbers, now the other service would have an extra row, which would not be accessible by any user in the future, so there would not be a risk for sharing sensitive information with others.

Describe the solution you’d like Use UUID V4 for generating all the IDs. Postgres, and likely other database systems have builtin function uuid_generate_v4() for this purpose. If some database does not have this kind of function, it could be generated by the application instead.

[michaelbromley]

product entity might need some other id. For example when importing from Magento, tracking pixels needs a specific id that’s similar to old store

This could be implemented via a custom field on Product.

Is there a reason why UUIDs are not the default option?

I think my reasoning was that integer IDs are more approachable and easier to work with in development.

[villesau]

I think my reasoning was that integer IDs are more approachable and easier to work with in development.

Makes kinda sense, numeric ids are indeed easier to reason about. Personally I’d prefer similar ids in dev & prod to make environments similar, and embracing uuids everywhere would be wise security vice.