Generate UUIDs for Database Primary Keys Across Servers

Auto-increment integers work fine until two databases need to create records independently, then merge. IDs collide, imports break and foreign keys point at the wrong rows. A UUID is a 128-bit identifier that can be generated anywhere without asking a central counter. The UUID Generator gives you values you can use as primary keys right now.

UUID Generator FREE online toolRuns in your browser. No sign-up, nothing to install. Open the tool

When a UUID key makes sense

Offline or mobile apps that create records before they can reach the server.
Several services or regions writing to separate databases that are later merged.
Public IDs in URLs where you do not want people to guess the next number or count your records.
Importing data from another system, where integer IDs would overlap.

Choose the version

Version 4 is random and the usual choice for primary keys: 122 of its 128 bits are random, so a collision is not a practical concern. Version 1 is built from a timestamp and a machine identifier, which sorts roughly by creation time but reveals when and where it was created. Version 5 is deterministic from a name and namespace and is meant for repeatable IDs, not for ordinary new rows.

Use generated values in your project

Choose version 4 in the generator and set the quantity you need, for example 50 seeds for a fixture file.
Copy the list and paste it into your SQL script, migration or JSON fixture.
Define the column with a native UUID type if your database has one (PostgreSQL does); otherwise use CHAR(36) or BINARY(16).
Insert one row and read it back to confirm formatting is accepted: lowercase hex with hyphens in an 8-4-4-4-12 pattern.
Add a unique constraint or primary key, then let the application generate future IDs in code.

Performance and storage notes

Random UUIDs scatter inserts across the index. On large tables in databases that cluster by primary key, such as InnoDB in MySQL, this can cause page splits and a bigger, slower index than sequential integers. Storing as 16 bytes instead of a 36-character string cuts the size by more than half.

If insert order matters for performance, consider time-ordered UUID formats designed for that purpose, or keep an integer clustered key and expose the UUID as a secondary public identifier. Measure with your own data before deciding; the trade-off depends on table size and query patterns.

Migrating an existing table

If you need to move from integers to UUIDs, add the UUID as a new unique column first, backfill it with generated values, update the references, and only then switch the primary key. Doing it in that order lets you roll back at each step. Test the migration on a copy of production data with realistic row counts before running it live.

Mistakes to avoid

Do not treat a UUID as a secret. A v4 value is hard to guess, but it is not an authorization token, so still check permissions on every request. Do not mix cases or formats inside one column, since comparing a string with braces to one without will fail. And do not generate IDs in the browser for production inserts when your server can do it, because client code can be altered.