Databases can store UUIDs well, but the details matter. Native UUID types, default generation, index behavior and public API needs all influence whether UUID v4, UUID v7 or a sequence is the best key.
Key takeaways
- Use native UUID types when your database supports them.
- Think about insert order before choosing UUID v4 for huge tables.
- Keep public identifiers and internal storage choices separate when needed.
PostgreSQL UUID columns
PostgreSQL has a native uuid type. That is usually the right choice for UUID fields because it validates the value and stores it compactly compared with a plain text column.
CREATE TABLE accounts (
id uuid PRIMARY KEY,
email text NOT NULL UNIQUE,
created_at timestamptz NOT NULL DEFAULT now()
);SQL Server GUID columns
SQL Server uses the uniqueidentifier type. Developers usually call these values GUIDs. Random GUID primary keys can fragment clustered indexes at high volume, so many teams use nonclustered primary keys, sequential GUID strategies or another clustering key.
CREATE TABLE dbo.Events (
Id uniqueidentifier NOT NULL PRIMARY KEY,
Name nvarchar(200) NOT NULL,
CreatedAt datetime2 NOT NULL
);MySQL UUID storage
MySQL teams often choose between CHAR(36), BINARY(16) and application-level UUID handling. CHAR(36) is easy to inspect. BINARY(16) is smaller but requires conversion functions and team discipline.
UUID v4 vs UUID v7 for indexes
UUID v4 values arrive in random order, which can make large B-tree indexes do more page splits. UUID v7 values sort closer to creation time, so they can be friendlier for append-heavy workloads.
That does not mean every table needs UUID v7. Small tables, low-write systems and public identifiers with sensitive timing concerns may still be fine with UUID v4.