Lesson 3 of 7

CREATE INDEX CONCURRENTLY: Building Indexes Online

Applies to PostgreSQL 13–17 Last reviewed May 2026 Grounded in source

The one thing to understand first

An ordinary CREATE INDEX takes a SHARE lock on the table for its entire duration. That lock permits reads but blocks all writes — every INSERT, UPDATE, and DELETE waits until the index finishes building, which on a large table can be many minutes. CREATE INDEX CONCURRENTLY (CIC) exists to build the index without blocking writes.

CONCURRENTLY trades wall-clock speed for availability: it scans the table twice and waits for old transactions to finish, but never blocks your writes — and if it fails it leaves an INVALID index you must clean up. Those two facts (the wait, and the INVALID-index aftermath) are where every CIC surprise comes from.

How CONCURRENTLY works

CIC trades speed for availability by doing two passes over the table with only a weak SHARE UPDATE EXCLUSIVE lock (which allows concurrent DML), defined in src/backend/commands/indexcmds.c:

This is a Pro lesson

Get every Learning Pathway and cookbook recipe — grounded in PostgreSQL source code, with diagnostics, fixes, and prevention for each topic.

Continue this lesson to learn:

  • The wait that surprises people
  • Handling failure: INVALID indexes
  • Rules and constraints
  • REINDEX CONCURRENTLY
  • Layer 3 — Watch it happen on your own database
  • Layer 4 — The levers this hands you
  • All 36 Learning Pathway lessons
  • 170+ cookbook recipes
  • Source-grounded diagnostics & fixes

Secure checkout Cancel anytime Source-grounded

Was this helpful?

← Back to 03 — Operations: Zero-Downtime Deployments