Indexes exist on columns used in WHERE, JOIN, and ORDER BY clauses

An unindexed email column means every login attempt performs a full table scan. An unindexed FK column means every JOIN on that relationship scans the entire child table. At 10,000 rows this is slow; at 100,000 rows it causes timeouts. Postgres does not automatically index FK columns — unlike MySQL — so every *_id column added by an ORM is unindexed until explicitly declared. ISO 25010 time-behaviour directly captures this: query latency degrades predictably as data volume grows, and the degradation is sharp rather than gradual when no index exists. Missed indexes on status or created_at columns produce full scans on the most common listing and filtering queries in the application.

Add @@index in Prisma or CREATE INDEX in SQL for every FK column, high-cardinality filter column (email, slug, external_id), and sort column (created_at) used in listing endpoints.

model Order {
  id     String @id @default(uuid())
  userId String
  status String
  @@index([userId])
  @@index([userId, status])
}

-- Add indexes without locking the table on Postgres
CREATE INDEX CONCURRENTLY idx_orders_user_id ON orders(user_id);
CREATE INDEX CONCURRENTLY idx_posts_created_at ON posts(created_at DESC);

For composite queries that filter on two columns together, a composite index beats two single-column indexes — verify query plans with EXPLAIN ANALYZE before and after.