How do I install the Surrealql Performance skill?

Run npx skillmds add surrealdb/surrealql-performance in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Surrealql Performance safe to use?

This skill has not completed SkillMD's automated safety review yet. Capability flags: makes network calls. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Surrealql Performance?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Surrealql Performance free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Surrealql Performance?

surrealdb (@surrealdb) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Surrealql Performance by surrealdb — Agent Skill

Name: Surrealql Performance
Rating: 4.5 (4 reviews)
Author: surrealdb

Surrealql Performance

Optimize SurrealDB performance through record ID and key design, indexing strategy, and computed/derived fields. Use when queries are slow, when designing record IDs for locality and range scans, choosing between standard/unique/full-text/vector indexes, verifying index usage with EXPLAIN, or deciding whether to precompute values with computed fields, views, or events. Triggers: slow query, performance, record id design, range scan, DEFINE INDEX, EXPLAIN, computed field, FUTURE, DEFINE TABLE AS SELECT.

surrealdb 76d8ead 4 files · 12.7 KB Updated Sep 9, 2026

File contents

SurrealQL Performance

Techniques for making SurrealDB queries fast: structuring record IDs and keys for data locality, choosing and verifying the right indexes, and precomputing values with computed fields and views instead of recomputing them on every read.

Target the latest stable SurrealDB release. Confirm version-sensitive syntax (record ranges, COMPUTED fields, FULLTEXT index options) against https://surrealdb.com/docs, and validate examples with surreal validate. See the surrealql skill for version detection.

When to use this skill

A query is slow or scans more records than expected
Designing record IDs to support efficient lookups and range scans
Choosing between standard, UNIQUE, full-text SEARCH, or vector indexes
Confirming whether an index is actually used (EXPLAIN)
Deciding whether to store a derived value vs. compute it on read

Topic map

Topic	Reference
Record ID & key structuring for locality and range scans	references/keys.md
Index types, composite order, verifying usage, rebuild cost	references/indexing.md
Computed fields, precomputed views, event-maintained values	references/computed-fields.md

Top rules

Design IDs for access patterns. Record IDs are stored in sorted order. Put the most selective, range-friendly component first (e.g. weather:['London', d'2025-02-13T05:00Z']) so related records sit together and range queries avoid full-table scans. See references/keys.md.
Prefer record ranges over WHERE on the ID. SELECT * FROM person:1..1000 uses key ordering directly; filtering with WHERE after a full scan does not.
Index the fields you filter, sort, or join on — but no more. Every index adds write cost. Order composite index fields from most to least selective and to match your query's filter/sort order. See references/indexing.md.
Verify, don't assume. Run EXPLAIN (or EXPLAIN FULL) to confirm a query uses the index you expect before concluding it is optimized.
Precompute expensive, read-heavy values. Use computed fields, a DEFINE TABLE ... AS SELECT view, or a DEFINE EVENT to maintain derived data rather than recomputing aggregates on every query. See references/computed-fields.md.
Use bound parameters. Parameterized queries are safer and let the engine reuse query plans.

---name: surrealql-performancedescription: Optimize SurrealDB performance through record ID and key design, indexing strategy, and computed/derived fields. Use when queries are slow, when designing record IDs for locality and range scans, choosing between standard/unique/full-text/vector indexes, verifying index usage with EXPLAIN, or deciding whether to precompute values with computed fields, views, or events. Triggers: slow query, performance, record id design, range scan, DEFINE INDEX, EXPLAIN, computed field, FUTURE, DEFINE TABLE AS SELECT.--- # SurrealQL Performance Techniques for making SurrealDB queries fast: structuring record IDs and keys for data locality, choosing and verifying the right indexes, and precomputing values with computed fields and views instead of recomputing them on every read. Target the **latest** stable SurrealDB release. Confirm version-sensitive syntax (record ranges, `COMPUTED` fields, `FULLTEXT` index options) against `https://surrealdb.com/docs`, and validate examples with `surreal validate`. See the `surrealql` skill for version detection. ## When to use this skill - A query is slow or scans more records than expected - Designing record IDs to support efficient lookups and range scans - Choosing between standard, `UNIQUE`, full-text `SEARCH`, or vector indexes - Confirming whether an index is actually used (`EXPLAIN`) - Deciding whether to store a derived value vs. compute it on read ## Topic map | Topic | Reference | | --- | --- | | Record ID & key structuring for locality and range scans | [references/keys.md](references/keys.md) | | Index types, composite order, verifying usage, rebuild cost | [references/indexing.md](references/indexing.md) | | Computed fields, precomputed views, event-maintained values | [references/computed-fields.md](references/computed-fields.md) | ## Top rules - **Design IDs for access patterns.** Record IDs are stored in sorted order. Put the most selective, range-friendly component first (e.g. `weather:['London', d'2025-02-13T05:00Z']`) so related records sit together and range queries avoid full-table scans. See [references/keys.md](references/keys.md). - **Prefer record ranges over `WHERE` on the ID.** `SELECT * FROM person:1..1000` uses key ordering directly; filtering with `WHERE` after a full scan does not. - **Index the fields you filter, sort, or join on — but no more.** Every index adds write cost. Order composite index fields from most to least selective and to match your query's filter/sort order. See [references/indexing.md](references/indexing.md). - **Verify, don't assume.** Run `EXPLAIN` (or `EXPLAIN FULL`) to confirm a query uses the index you expect before concluding it is optimized. - **Precompute expensive, read-heavy values.** Use computed fields, a `DEFINE TABLE ... AS SELECT` view, or a `DEFINE EVENT` to maintain derived data rather than recomputing aggregates on every query. See [references/computed-fields.md](references/computed-fields.md). - **Use bound parameters.** Parameterized queries are safer and let the engine reuse query plans.

Frequently asked questions