UUID Auto Generate Postgres: Defaults That Work

The column definition

-- PostgreSQL 13+ : random v4, no extension needed
CREATE TABLE users (
    id         uuid PRIMARY KEY DEFAULT gen_random_uuid(),
    created_at timestamptz NOT NULL DEFAULT now()
);

-- PostgreSQL 18+ : time-ordered v7
CREATE TABLE events (
    id uuid PRIMARY KEY DEFAULT uuidv7()
);

Older guides tell you to CREATE EXTENSION "uuid-ossp" and call uuid_generate_v4(). That has been unnecessary since Postgres 13 — gen_random_uuid() is built in.

Use the native type

The uuid type stores 16 bytes. Storing the text form in varchar(36) costs 37 bytes plus overhead, more than doubling index size and slowing every comparison.

It also validates: a malformed value is rejected at write time rather than discovered later. There is no reason to use a text column for a UUID in PostgreSQL.

v4 or v7 for the key

v4 scatters inserts across the index, so pages split constantly and the hot part of the index does not fit in shared buffers. On a large, write-heavy table the difference is substantial.

v7 clusters inserts at the right edge like a sequence, keeping the working set small. If you are on Postgres 18 use uuidv7(); below that, generate v7 in the application and keep gen_random_uuid() as the fallback default.

A bigint identity column is still faster and smaller than any UUID. Choose a UUID when you need client-side generation or want to avoid exposing row counts — not by default.

Application-side defaults

Generating the id in the application lets you use it before the insert completes — useful for building related rows in one round trip. Keep the database default as well, so a direct insert still gets a valid id.

With an ORM, make sure it does not fetch the generated value with an extra round trip when it could have generated it locally.