How to Store UUIDs in PostgreSQL, MySQL and SQL Server

PostgreSQL: use the native uuid type

PostgreSQL has a first-class uuid type. It validates values on the way in and stores them in 16 bytes, which is far more efficient than a text column. PostgreSQL 18 includes uuidv7() for UUID v7 and uuidv4() for UUID v4; gen_random_uuid() remains an alias for UUID v4. On older releases, generate v7 in your application or with a carefully reviewed extension.

CREATE TABLE orders (
  id uuid PRIMARY KEY,
  customer_id uuid NOT NULL,
  created_at timestamptz NOT NULL DEFAULT now()
);
CREATE INDEX ON orders (customer_id);

MySQL: BINARY(16) or CHAR(36)?

MySQL has no dedicated UUID type, so you choose the representation. CHAR(36) is human-readable and easy to inspect but uses more than twice the space and indexes less tightly. BINARY(16) stores the raw bytes compactly and is the better default for large tables, at the cost of converting with UUID_TO_BIN and BIN_TO_UUID.

UUID v7 already puts its timestamp first, so store it with UUID_TO_BIN(?) without MySQL’s swap flag. The swap flag was designed to rearrange UUID v1 fields and should only be used when the corresponding read and write paths deliberately use that representation.

-- Compact storage for a canonical UUID v7 string
INSERT INTO users (id) VALUES (UUID_TO_BIN(?));
SELECT BIN_TO_UUID(id) AS id FROM users;

SQL Server: uniqueidentifier and clustering

SQL Server stores UUIDs as uniqueidentifier (16 bytes) and developers usually call them GUIDs. The classic pitfall is making a random GUID the clustered primary key, which fragments the clustered index on every insert. Options are to use a nonclustered primary key, cluster on a sequential column, or use a sequential-GUID strategy so new keys sort in order.

The version decision applies everywhere

Across all three engines the same principle holds: random UUID v4 keys scatter inserts, and time-ordered UUID v7 keys append. On small or low-write tables either is fine. On high-write tables, prefer an ordered scheme and store the bytes compactly. Keep public exposure separate from storage if the creation time embedded in v7 is sensitive.