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

Random UUID v4 keys can scatter B-tree inserts. UUID v7 can improve locality in PostgreSQL and with unswapped binary bytes in MySQL, but SQL Server uniqueidentifier uses its own comparison order. Do not assume a UUID v7 clustered key is sequential there; benchmark your workload and consider a separate sequential clustering key. Creation time in v7 may also be visible to public clients.