just-vibeDatabases · plan by default
/db-index
Recommend indexes based on queries, write costs, and measurements
Use for workload-specific index design; db-schema handles broader constraints and data shape.
Make it your own.
In Claude Code, use the slash command and add your context. In Codex, select db-index from the just-vibe skill picker, then send the same brief.
Version 0.11.0 also supports /jv db-index, /just-vibe db-index and /jv:db-index in Claude. See shortcut setup and context examples.
/just-vibe:db-index Recommend indexes from these query plans, including write and storage costs./just-vibe:db-index Design an index for a tenant-filtered timeline with a stable secondary sort key./just-vibe:db-index Assess indexing from schema without plans or workload counts; label performance estimates unknown.What the agent does
- Match equality, range and order predicates and their selectivity to existing indexes.
- Estimate write and storage cost from evidence, and design the before/after measurement on the exact workload and an online-creation strategy where supported.
Inputs
- actual queries/plans, schema/indexes, write workload, engine, and storage constraints.
Optional context: scope, references, constraints, successCriteria, environment, mode, budget.
Scope
- Reads
- Evidence-based index design, redundancy, and rollout; no automatic production DDL.
- Writes
- No source changes in inspect/plan. Save only requested planning artifacts. db-migrate applies an accepted index change.
- Mode
- Plan; actual queries/plans, schema/indexes, write workload, engine, and storage constraints.
- Prerequisites
- Actual engine/version, schema/migrations, query workload, and explicitly identified environment. Prefer supplied plans, metadata, and isolated fixtures. Even a SELECT can lock, call mutating functions, or overload a database; inspect semantics before execution. Executing an analyzed query is distinct from reading its plan.
Expected output
- Candidate index definition with the workload it supports, redundant overlap, a measured validation plan and a rollout proposal for db-migrate.
How the work is checked
- Target query improves under comparable conditions; added write cost and redundant indexes are considered.
When to stop or clarify
- Do not recommend indexes from column names alone. Unsupported online operations or lock risks must be addressed before execution.
Handling missing context
- Infer
- Read engine/version, ORM/runner, schema and migration history from project artifacts before choosing SQL.
- Assume
- Prepare local SQL and isolated fixtures without assuming production size, locks or recovery guarantees.
- Ask
- Ask for environment, downtime or recovery constraints before live/destructive execution when missing; unavailable production access does not block migration files.
Technical guidance
- Evidence
- Inspect real predicates, ordering, selectivity, existing index definitions and write volume.
- Method
- Choose key order, covering/partial options and rollout method using supported engine behavior and measured plans.
- Pitfall
- More indexes increase write/storage cost; an index on a low-selectivity column may not improve the actual workload.
- Check
- Compare read plans/latency and representative write cost; verify validity after online/concurrent creation before declaring completion.
Situational decisions
When an existing index shares the proposed name: Inspect definition and validity before reuse; an IF NOT EXISTS notice is not a compatibility check.
The coding agent follows this workflow using its available tools. Installation does not grant service access or guarantee an outcome. Read the compatibility notes.