1---
2title: Select Optimal Primary Key Strategy
3impact: HIGH
4impactDescription: Better index locality, reduced fragmentation
5tags: primary-key, identity, uuid, serial, schema
6---
7 
8## Select Optimal Primary Key Strategy
9 
10Primary key choice affects insert performance, index size, and replication
11efficiency.
12 
13**Incorrect (problematic PK choices):**
14 
15```sql
16-- identity is the SQL-standard approach
17create table users (
18  id serial primary key  -- Works, but IDENTITY is recommended
19);
20 
21-- Random UUIDs (v4) cause index fragmentation
22create table orders (
23  id uuid default gen_random_uuid() primary key  -- UUIDv4 = random = scattered inserts
24);
25```
26 
27**Correct (optimal PK strategies):**
28 
29```sql
30-- Use IDENTITY for sequential IDs (SQL-standard, best for most cases)
31create table users (
32  id bigint generated always as identity primary key
33);
34 
35-- For distributed systems needing UUIDs, use UUIDv7 (time-ordered)
36-- Requires pg_uuidv7 extension: create extension pg_uuidv7;
37create table orders (
38  id uuid default uuid_generate_v7() primary key  -- Time-ordered, no fragmentation
39);
40 
41-- Alternative: time-prefixed IDs for sortable, distributed IDs (no extension needed)
42create table events (
43  id text default concat(
44    to_char(now() at time zone 'utc', 'YYYYMMDDHH24MISSMS'),
45    gen_random_uuid()::text
46  ) primary key
47);
48```
49 
50Guidelines:
51 
52- Single database: `bigint identity` (sequential, 8 bytes, SQL-standard)
53- Distributed/exposed IDs: UUIDv7 (requires pg_uuidv7) or ULID (time-ordered, no
54  fragmentation)
55- `serial` works but `identity` is SQL-standard and preferred for new
56  applications
57- Avoid random UUIDs (v4) as primary keys on large tables (causes index
58  fragmentation)
59 
60Reference:
61[Identity Columns](https://www.postgresql.org/docs/current/sql-createtable.html#SQL-CREATETABLE-PARMS-GENERATED-IDENTITY)
62