Index Types in AetheriusDB

ReferenceIndexingPerformance

This page is the consolidated list of index types in AetheriusDB. It covers what each method is for and when to pick it; the tuning parameters and full DDL live on the linked pages.

What types of indexes does AetheriusDB support?

AetheriusDB supports five index methods on CREATE INDEX, plus a separate graph index family:

Index type	Created with	Accelerates
PTI	`USING PTI`	Grouped aggregates, answered from pre-computed mirrors
B-Tree	`USING BTREE` (the default)	Range scans, sorting, equality, `UNIQUE` enforcement
Hash	`USING HASH`	Single-value equality lookups
HNSW	`USING HNSW`	Approximate k-nearest-neighbour over `TENSOR(n)` columns
IVFFLAT	`USING IVFFLAT`	Approximate k-nearest-neighbour, faster to build than HNSW
Graph index	`CREATE GRAPH INDEX`	Navigational joins along a declared relationship

UNIQUE and partial (WHERE …) indexes are modifiers, not separate methods — they can be applied to the tree-based index types. Omitting USING gives you a B-Tree.

What is a PTI index?

The Polyphonic Tensor Index (PTI) is AetheriusDB’s aggregate-accelerating index. A classical B+ tree stores only keys and pointers, so computing a sum or count still means walking to the leaves and adding values up. Each PTI branch node additionally carries pre-aggregated mirrors of the data beneath it — sum, count, avg, min, and max.

When a grouped aggregate can be answered from those mirrors, AetheriusDB returns the result without scanning the table at all, and prunes whole subtrees that cannot match. Use PTI for GROUP BY reporting queries over large tables.

When should I use a B-Tree index?

A B-Tree index is the default in AetheriusDB and the right choice for most ordinary indexing. It handles range predicates (<, >, BETWEEN), equality, ORDER BY support, and enforces UNIQUE constraints by probing rather than scanning.

If you are unsure which index to create, create a B-Tree. It is what you get when you write CREATE INDEX without a USING clause.

When should I use a Hash index?

A Hash index in AetheriusDB serves single-value equality lookups — WHERE id = ? — and nothing else. It cannot answer range queries or support sorting, because a hash has no order.

Choose Hash over B-Tree only when the column is queried exclusively by exact equality and you want the tighter lookup. When in doubt, a B-Tree covers the equality case too and stays useful if your query patterns broaden.

What is an HNSW index?

HNSW (Hierarchical Navigable Small World) is a vector index for approximate k-nearest-neighbour search over TENSOR(n) columns in AetheriusDB. It builds a navigable multi-layer graph of the vectors, which gives high recall at low query latency.

Use HNSW for semantic search, recommendations, and RAG retrieval where query speed and recall matter more than index build time. Its tuning knobs are m and ef_construction at build time, and ef_search at query time — higher values trade speed for recall.

What is an IVFFLAT index?

IVFFLAT is the other vector index in AetheriusDB. It partitions vectors into lists clusters and searches only the nearest probes of them at query time.

Compared to HNSW it builds substantially faster and uses less memory, at the cost of lower recall for the same query latency. Choose IVFFLAT when you re-index often or hold a very large number of vectors; choose HNSW when retrieval quality is the priority.

What is a graph index?

A graph index is a separate DDL family in AetheriusDB, created with CREATE GRAPH INDEX … ON LINKS (…) and a declared CARDINALITY of '1:1' or '1:N'. Rather than indexing values in a column, it records a relationship between tables so the engine can navigate directly from a row to its related rows.

Use a graph index for joins along a fixed, well-known relationship that your workload traverses repeatedly — the foreign-key paths your application walks on nearly every query.

Which index should I choose?

Grouped aggregates / GROUP BY reporting → PTI
Range queries, sorting, or UNIQUE → B-Tree (also the default)
Only exact-equality lookups → Hash
Vector similarity, quality first → HNSW
Vector similarity, fast build or very large sets → IVFFLAT
Repeated traversal of a fixed relationship → graph index
Indexing only part of a table → add a WHERE clause to make it partial

Notes & caveats

Two SQL clauses in AetheriusDB use the word USING but are not index methods, and are easy to confuse with one:

USING HILBERT 2D inside CREATE TABLE is a column spatial-locality encoding, which controls how rows are physically ordered — not an index.
USING ALLOCATION 'proportional' is an option on pivot operations, unrelated to indexing.

The index method after USING is parsed as a free-form identifier, so an unrecognised name is not rejected at parse time. Check the spelling against the five supported methods above.

Advanced Indexing (PTI) →

PTI internals, partial indexes, REINDEX, and autonomous indexing.

Vector Search →

HNSW vs IVFFLAT tuning parameters in depth.

Graph Index →

Navigational joins along declared relationships.

SQL Grammar →

The authoritative CREATE INDEX syntax.

Table Types →

Every kind of table these indexes can be built on.