A native 128-bit column type for storing universally unique identifiers, distinct from storing UUIDs as plain strings.
Globally unique identifiers that can be generated independently across systems without coordination, unlike auto-increment. UUIDs avoid ID conflicts in distributed systems but are larger (16 bytes), slower to index, and harder to debug. Consider UUID v7 for time-ordered IDs.
| Database System | Support Status | Since Version | Notes |
|---|---|---|---|
| MySQL | ✗ Not Supported | — | No native UUID column type. Common options: CHAR(36) for human-readable storage, or BINARY(16) with UUID_TO_BIN() / BIN_TO_UUID() (8.0+) for efficient indexed storage. BINARY(16) is strongly preferred for primary keys. |
| PostgreSQL | ✓ Supported | 8.3 | Native UUID type stores 16 bytes internally (no hyphen overhead). Displays as the standard 8-4-4-4-12 hyphenated string. Supports equality, indexing, and default expressions with gen_random_uuid(). |
| SQL Server | ✓ Supported | 2000 | UNIQUEIDENTIFIER is the native 16-byte UUID type. Supports NEWID() and NEWSEQUENTIALID() as defaults. Note: SQL Server stores bytes in a mixed-endian order that differs from RFC 4122, which affects cross-platform comparisons. |
| Oracle | ✗ Not Supported | — | No native UUID column type. SYS_GUID() returns RAW(16), and RAW(16) is the conventional storage type for UUIDs. The standard hyphenated format requires manual conversion. |
| SQLite | ✗ Not Supported | — | No native UUID type. Store as TEXT (36-char hyphenated string) or BLOB (16 bytes). TEXT is more portable; BLOB is more space-efficient. |
PostgreSQL and SQL Server are the only engines with a true native UUID column type that stores 16 bytes internally and handles formatting transparently. MySQL requires a deliberate choice between CHAR(36) (readable, wasteful) and BINARY(16) (efficient but requires conversion functions on read/write). Oracle's RAW(16) is functional but the formatting overhead is significant. A critical SQL Server gotcha: UNIQUEIDENTIFIER byte order is not standard RFC 4122 — the first three components are stored in little-endian order, which causes the displayed string to differ from what other systems would show for the same 16 bytes. This matters when exchanging UUIDs with non-SQL-Server systems. For random (v4) UUIDs as clustered primary keys in SQL Server, prefer NEWSEQUENTIALID() to avoid index fragmentation.
No native UUID column type. Common options: CHAR(36) for human-readable storage, or BINARY(16) with UUID_TO_BIN() / BIN_TO_UUID() (8.0+) for efficient indexed storage. BINARY(16) is strongly preferred for primary keys.
Native UUID type stores 16 bytes internally (no hyphen overhead). Displays as the standard 8-4-4-4-12 hyphenated string. Supports equality, indexing, and default expressions with gen_random_uuid().
UNIQUEIDENTIFIER is the native 16-byte UUID type. Supports NEWID() and NEWSEQUENTIALID() as defaults. Note: SQL Server stores bytes in a mixed-endian order that differs from RFC 4122, which affects cross-platform comparisons.
No native UUID column type. SYS_GUID() returns RAW(16), and RAW(16) is the conventional storage type for UUIDs. The standard hyphenated format requires manual conversion.
No native UUID type. Store as TEXT (36-char hyphenated string) or BLOB (16 bytes). TEXT is more portable; BLOB is more space-efficient.