DynamoDB GSI Design: Design Your Queries Before Your Schema

The relational instinct is to design tables first, then figure out queries. DynamoDB inverts that order and punishes anyone who forgets. I learned this by rebuilding a table at week six.

Start With Access Patterns

Before touching the table definition, I write down every read and write pattern the app needs. Literally every one. Get post by slug. List posts by category ordered by date. List drafts by author. Each pattern becomes a constraint on the key design.

A single-table design with a handful of GSIs can serve ten access patterns if you plan the keys up front. The same table with ad-hoc GSIs becomes expensive, slow, or both.

The Pattern I Actually Use

PK              SK                  GSI1PK          GSI1SK
POST#abc123     META                CATEGORY#tech   2025-07-01#abc123
POST#abc123     VERSION#1           -               -
USER#chadi      POST#abc123         -               -

The main table answers get post by id and list posts by user. GSI1 answers list posts by category ordered by date. That is three access patterns on one table with one index. No joins. No scans.

The Rule

If you are reaching for a scan or a filter expression in production, the schema is wrong. Filters run after the read, so you pay for rows you discard. Redesign the keys.

The DynamoDB single-table design guide has the canonical examples. Read it before you design your first GSI, not after.