All Docs
FeaturesDepositClearUpdated March 6, 2026

v0.1.1: Database Performance & CI Foundations

v0.1.1: Database Performance & CI Foundations

This release is a focused infrastructure patch. No user-visible features changed, but the platform is now significantly more efficient under load and gains a CI pipeline for all future pull requests.

Why indexes matter here

Several core platform queries are issued on every authenticated request — membership lookups, subscription checks, notification polling — meaning they scale directly with traffic. Without indexes, each of those queries performs a full sequential scan of the table, reading every row to find matches. As data grows, response times grow linearly with it.

The 10 indexes added in this release convert those scans into direct index seeks. On tables that accumulate unbounded rows over time (audit_log records every action, usage_events records every billable event) the difference between a sequential scan and an index seek becomes the difference between a query taking milliseconds versus seconds at production data volumes.

Indexes added

org_members (2 indexes)

org_members_org_id_idx
org_members_user_id_idx

The orgProcedure tRPC middleware resolves the current organisation on every authenticated API call. These two single-column indexes ensure those lookups are always index seeks regardless of how many members exist across all orgs.

org_invites (1 composite index)

org_invites_org_id_status_idx  (org_id, status)

The pending-invite listing query filters on both org_id and status simultaneously. The composite index covers both predicates in one seek.

subscriptions (1 index)

subscriptions_org_id_idx

Queried on every billing check and seat-limit enforcement call.

usage_events (1 composite index)

usage_events_org_id_created_at_idx  (org_id, created_at)

Billing aggregation queries scan a time range within an org. The composite index supports the WHERE org_id = ? AND created_at BETWEEN ? AND ? pattern directly.

audit_log (2 composite indexes)

audit_log_org_id_created_at_idx  (org_id, created_at)
audit_log_org_id_action_idx      (org_id, action)

The activity feed paginates in reverse-chronological order (ORDER BY created_at DESC). The first index supports that pattern. The second supports filtering the feed by action type. Both share the leading org_id column so they partition data by tenant first.

webhook_deliveries (1 index)

webhook_deliveries_webhook_id_idx

Delivery history is always looked up by webhook, not globally.

batch_runs (1 index)

batch_runs_batch_job_id_idx

Execution history is always looked up by the parent batch job.

notifications (1 composite index)

notifications_org_id_user_id_read_idx  (org_id, user_id, read)

The unread notification count is polled every 30 seconds by the frontend. This composite index covers WHERE org_id = ? AND user_id = ? AND read = false in a single seek and is critical to keeping that background poll cheap.

Applying the migration

This release requires a database migration. Run the following after deploying:

# 1. Generate the migration file
npx drizzle-kit generate

# 2. Apply it to your database
npx drizzle-kit migrate
# — or, for development environments —
npx drizzle-kit push

The migration only adds indexes. It does not alter column definitions or delete data, so it is safe to apply to an existing populated database with no downtime risk beyond the brief time Postgres spends building each index.

Bug fixes shipped in the same release

Webpack compile failure on layout.tsx and page.tsx

The initial project scaffold contained invalid quote characters inside string literals in src/app/layout.tsx (the metadata.description field) and src/app/page.tsx (hero section copy). These caused webpack to fail at compile time, preventing npm run build from completing. Both files have been corrected.

CI pipeline

A GitHub Actions workflow (.github/workflows/ci.yml) is now active on the repository. It runs automatically on every push to main and every pull request targeting main.

What the workflow does:

  1. Checks out the code on Node 20.
  2. Runs npm install.
  3. Runs npm run build — the Next.js production build.
  4. Runs npm test — the Vitest suite (passes cleanly if no test files exist yet).

The workflow uses stub environment variables so the build can complete without a live database or external service credentials.