db: composite index on releases (published_at, id) (#762)

db: composite index on releases (published_at, id) for cursor walks (#756)

GraphQL latestReleases and REST /v1/orgs/:slug/releases both order by
(published_at DESC, id DESC) and tiebreak the cursor on id when
published_at is equal. The existing idx_releases_published only covers
published_at alone, so ties (common — batch ingest stamps dozens of rows
with one poll-cycle timestamp) force a temp B-tree filesort over the
tied range.

Add a hand-authored DESC composite index. Drizzle's index() helper
doesn't emit direction, so the schema declaration is best-effort; the
migration carries the real DDL.

Verified on staging via EXPLAIN QUERY PLAN:
- Before: SEARCH USING INDEX idx_releases_published (published_at<?)
          + USE TEMP B-TREE FOR LAST TERM OF ORDER BY
- After:  SEARCH USING COVERING INDEX idx_releases_published_id (published_at<?)

Single-column idx_releases_published is left in place — many REST queries
still filter/order on published_at alone and the optimizer may prefer the
narrower index for those scans. Drop is a follow-up if EXPLAIN later
shows it unused.

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: zachdunn

packages/core/src/schema.ts

@@ -270,6 +270,11 @@ export const releases = sqliteTable(
     uniqueIndex("idx_releases_source_url").on(table.sourceId, table.url),
     index("idx_releases_source_published").on(table.sourceId, table.publishedAt),
     index("idx_releases_published").on(table.publishedAt),
+    // Covers `(published_at DESC, id DESC)` cursor walks — GraphQL `latestReleases`
+    // and REST `/v1/orgs/:slug/releases`. Drizzle's index() helper doesn't emit
+    // direction modifiers, so the matching DESC index is hand-authored in the
+    // migration file (20260506000000_releases_published_id_index.sql).
+    index("idx_releases_published_id").on(table.publishedAt, table.id),
     index("idx_releases_source_suppressed_published").on(
       table.sourceId,
       table.suppressed,

workers/api/migrations/20260506000000_releases_published_id_index.sql

@@ -0,0 +1,23 @@
+-- #756: composite index for (published_at DESC, id DESC) cursor walks.
+--
+-- The GraphQL `latestReleases` resolver and REST `/v1/orgs/:slug/releases`
+-- both order by `(published_at DESC, id DESC)` and tiebreak the cursor on
+-- `id` when `published_at` is equal. The existing `idx_releases_published`
+-- only covers `published_at` alone, so ties on `published_at` (common —
+-- batch ingest stamps dozens of rows with a single poll-cycle timestamp)
+-- force a filesort over the tied range.
+--
+-- DESC ordering is explicit because SQLite can walk a DESC index forward
+-- to satisfy `ORDER BY ... DESC` without a reverse-scan plan, which keeps
+-- the cursor predicate (`(published_at, id) < (?, ?)`) on the optimizer's
+-- happy path. (An ASC index would also work — SQLite reverses scans
+-- transparently — but matching the ORDER BY direction is the conservative
+-- pick and avoids relying on the reverse-scan optimizer staying smart.)
+--
+-- The single-column `idx_releases_published` is intentionally NOT dropped
+-- here. Many REST endpoints filter or order on `published_at` alone, and
+-- although the composite's leading column can serve those queries, the
+-- single-column index is physically smaller and may be the optimizer's
+-- pick for narrow scans. Drop is a follow-up if/when EXPLAIN shows the
+-- single-column form is unused.
+CREATE INDEX idx_releases_published_id ON releases (published_at DESC, id DESC);