Storing UUIDs in Databases — Binary vs String

Published by UUID Generator Team

A UUID is 128 bits (16 bytes). You can store it as a string (e.g. CHAR(36) or VARCHAR(36)) or as binary (BINARY(16) or a native uuid type). Each approach has trade-offs.

String (36 characters)

Store the canonical form with hyphens: 550e8400-e29b-41d4-a716-446655440000. Pros: human-readable in queries and logs, no conversion when sending to APIs. Cons: 36 bytes (or more with charset), larger indexes and slower comparisons in some engines.

Binary (16 bytes)

Store the raw 128 bits, usually by removing hyphens and converting hex to bytes. Pros: half the storage of a 36-char string, faster comparisons and smaller indexes. Cons: not readable in raw form; you must encode/decode when reading or sending to clients.

Native UUID Type

PostgreSQL and a few others have a uuid type (16 bytes internally). Use it when available: best of both worlds—efficient storage and built-in parsing/formatting. MySQL has no native UUID type; use CHAR(36) or BINARY(16).

Recommendation

Prefer native uuid where supported. Otherwise: use BINARY(16) for high volume and performance; use CHAR(36) when readability and simplicity matter more than size. Validate input with our validator or API before storing.

UUID in SQL · UUID as primary key · Home