Generate SQL-ready UUID values for seed data, migration rehearsals and database tests. Match the output to the database’s native UUID representation and keep constraints in place so copied fixtures cannot create silent duplicates.
Key takeaways
- Prefer PostgreSQL uuid or SQL Server uniqueidentifier over generic text.
- Use BINARY(16) deliberately when compact MySQL storage is worth the conversion step.
- Treat generated INSERT text as seed data, not as a substitute for runtime ID policy.
For implementation context, continue with SQL, Database Guide, and Bulk UUIDs. These pages cover the closest generator, comparison, validation or storage decisions without repeating this guide.
Use the database-native type
PostgreSQL validates a uuid column and SQL Server provides uniqueidentifier. MySQL commonly uses CHAR(36) for readability or BINARY(16) for compact indexes. Pick the storage type before generating seed statements.
Native or compact binary storage prevents inconsistent case and punctuation from becoming distinct text keys.
Quote, cast and parameterize
Static seed files usually quote UUID literals. Application code should use prepared statements and typed parameters rather than concatenating generated identifiers into SQL. Parameterization protects the full statement, not just the UUID field.
Keep the unique constraint
Correctly generated UUID collisions are extraordinarily unlikely, but copied fixtures and repeated migrations are ordinary engineering mistakes. A primary key or unique index turns those mistakes into an explicit failure.