|
| 1 | +--- |
| 2 | +name: redis-query-engine |
| 3 | +description: Redis Query Engine (RQE) guidance covering FT.CREATE schema design, field type selection (TEXT, TAG, NUMERIC, GEO, GEOSHAPE, VECTOR), DIALECT 2 query syntax, efficient FT.SEARCH and FT.AGGREGATE queries, zero-downtime index updates via aliases, and the SKIPINITIALSCAN option. Use when defining a search index on Hash or JSON documents, picking between TEXT and TAG for filtering, writing FT.SEARCH queries with filters and SORTBY, managing or swapping indexes in production, or troubleshooting slow searches with FT.PROFILE. |
| 4 | +license: MIT |
| 5 | +metadata: |
| 6 | + author: Redis, Inc. |
| 7 | + version: "0.1.0" |
| 8 | +--- |
| 9 | + |
| 10 | +# Redis Query Engine |
| 11 | + |
| 12 | +Guidance for using the Redis Query Engine (RQE) to index and search Hash or JSON documents. Covers schema design with `FT.CREATE`, field-type choices, query syntax, index lifecycle management, and the most common performance pitfalls. |
| 13 | + |
| 14 | +## When to apply |
| 15 | + |
| 16 | +- Creating, modifying, or reviewing an RQE index (`FT.CREATE`, `FT.ALTER`). |
| 17 | +- Writing or optimizing `FT.SEARCH` / `FT.AGGREGATE` queries. |
| 18 | +- Deciding between `TEXT`, `TAG`, `NUMERIC`, `GEO`, `GEOSHAPE`, or `VECTOR` for a field. |
| 19 | +- Rolling out a new index schema without downtime. |
| 20 | +- Spinning up an index that should only cover newly written keys. |
| 21 | + |
| 22 | +## 1. Use DIALECT 2 (the modern default) |
| 23 | + |
| 24 | +`DIALECT 2` is the baseline. Other dialects (1, 3, 4) are deprecated as of Redis 8. Most modern client libraries already default to it — but specify it explicitly in raw commands for portability. |
| 25 | + |
| 26 | +``` |
| 27 | +FT.SEARCH idx:products "@name:laptop" DIALECT 2 |
| 28 | +``` |
| 29 | + |
| 30 | +`DIALECT 2` is **required** for vector search queries. It also handles special characters and NULLs predictably. |
| 31 | + |
| 32 | +See [references/dialect.md](references/dialect.md). |
| 33 | + |
| 34 | +## 2. Pick the right field type |
| 35 | + |
| 36 | +The field type decides both what you can query and how fast that query is. Use the narrowest type that supports your access pattern. |
| 37 | + |
| 38 | +| Field type | Use when | Notes | |
| 39 | +|---|---|---| |
| 40 | +| `TEXT` | Full-text search needed | Tokenized + stemmed; **not** for exact match | |
| 41 | +| `TAG` | Exact match / filtering | Add `SORTABLE UNF` for fastest tag queries | |
| 42 | +| `NUMERIC` | Range queries, sorting | Prices, counts, timestamps | |
| 43 | +| `GEO` | Lat/long point queries | Single points (stores, users) | |
| 44 | +| `GEOSHAPE` | Polygon / area queries | Delivery zones, regions | |
| 45 | +| `VECTOR` | Similarity search | HNSW or FLAT; see redis-vector-search | |
| 46 | + |
| 47 | +The classic mistake is using `TEXT` for a category or status field because "it's a string." `TAG` is 10× faster for those. |
| 48 | + |
| 49 | +See [references/field-types.md](references/field-types.md). |
| 50 | + |
| 51 | +## 3. Index only what you query — and always set a prefix |
| 52 | + |
| 53 | +`FT.CREATE` without a `PREFIX` indexes **every** matching key in the database; with a wide schema it can blow up index size and write latency. |
| 54 | + |
| 55 | +``` |
| 56 | +FT.CREATE idx:products ON HASH PREFIX 1 product: |
| 57 | + SCHEMA |
| 58 | + name TEXT WEIGHT 2.0 |
| 59 | + category TAG SORTABLE |
| 60 | + price NUMERIC SORTABLE |
| 61 | + location GEO |
| 62 | +``` |
| 63 | + |
| 64 | +Rules of thumb: |
| 65 | + |
| 66 | +- Start with the minimum schema. Add fields as new query patterns emerge. |
| 67 | +- Always set `PREFIX` (or filter via `FILTER` expression). |
| 68 | +- Use `FT.INFO idx:<name>` to monitor index size after adding fields. |
| 69 | +- Use `SORTABLE` only on fields you actually sort by; it has a memory cost. |
| 70 | + |
| 71 | +See [references/index-creation.md](references/index-creation.md). |
| 72 | + |
| 73 | +## 4. Zero-downtime index updates — use aliases |
| 74 | + |
| 75 | +For schema changes in production, keep application queries pointed at an alias and swap the underlying index. |
| 76 | + |
| 77 | +``` |
| 78 | +FT.CREATE idx:products_v2 ON HASH PREFIX 1 product: SCHEMA ... |
| 79 | +FT.ALIASUPDATE products idx:products_v2 |
| 80 | +
|
| 81 | +# App queries are stable: |
| 82 | +FT.SEARCH products "@category:{electronics}" |
| 83 | +``` |
| 84 | + |
| 85 | +Useful management commands: `FT.INFO`, `FT.DROPINDEX`, `FT._LIST`, `FT.ALIASADD/UPDATE/DEL`. |
| 86 | + |
| 87 | +See [references/index-management.md](references/index-management.md). |
| 88 | + |
| 89 | +## 5. SKIPINITIALSCAN — only when historical data is irrelevant |
| 90 | + |
| 91 | +By default `FT.CREATE` walks all existing keys that match the prefix and indexes them. Use `SKIPINITIALSCAN` only when: |
| 92 | + |
| 93 | +- You're standing up the index for a *new* feature and existing data shouldn't be queryable. |
| 94 | +- Existing data is too large to scan synchronously. |
| 95 | +- You're indexing event streams where only future events matter. |
| 96 | + |
| 97 | +For most schema migrations, the default (scan everything) is what you want. |
| 98 | + |
| 99 | +See [references/skip-initial-scan.md](references/skip-initial-scan.md). |
| 100 | + |
| 101 | +## 6. Write specific queries, not `*` |
| 102 | + |
| 103 | +Narrow the result set with filters before paging or aggregating. |
| 104 | + |
| 105 | +``` |
| 106 | +# Good — specific filter, limited fields returned |
| 107 | +FT.SEARCH idx:products "@category:{electronics} @price:[100 500]" |
| 108 | + LIMIT 0 20 |
| 109 | + RETURN 3 name price category |
| 110 | +``` |
| 111 | + |
| 112 | +``` |
| 113 | +# Bad — full scan plus unbounded LIMIT |
| 114 | +FT.SEARCH idx:products "*" LIMIT 0 10000 |
| 115 | +``` |
| 116 | + |
| 117 | +Other levers: |
| 118 | + |
| 119 | +- `SORTBY` requires `SORTABLE` on the sort field. Without it, sort is slow. |
| 120 | +- `LIMIT` early; the engine still processes everything above the limit if you don't. |
| 121 | +- `RETURN` specific fields — don't fetch the whole document if you only need a few. |
| 122 | +- Profile with `FT.PROFILE idx:<name> SEARCH QUERY "<query>"` when a query is slow. |
| 123 | + |
| 124 | +See [references/query-optimization.md](references/query-optimization.md). |
| 125 | + |
| 126 | +## References |
| 127 | + |
| 128 | +- [Redis: Query Engine — Indexing](https://redis.io/docs/latest/develop/interact/search-and-query/indexing/) |
| 129 | +- [Redis: Query syntax](https://redis.io/docs/latest/develop/interact/search-and-query/query/) |
| 130 | +- [Redis: Query dialects](https://redis.io/docs/latest/develop/interact/search-and-query/advanced-concepts/dialects/) |
| 131 | +- [Redis: Administration (aliases, dropindex)](https://redis.io/docs/latest/develop/interact/search-and-query/administration/) |
| 132 | +- [FT.CREATE](https://redis.io/docs/latest/commands/ft.create/) |
0 commit comments