Skip to content
Course content preview

25: Defining indexes

Indexes can be defined in SurrealDB for a number of ways. The main reason for an index is faster data retrieval. This is used most often when you need to use the WHERE clause in a query, which results in a full table scan. But with an index, this is much faster.

CREATE person SET name = "Billy";
-- Create 25000 more records, each with a random string for a name
CREATE |person:25000| SET name = rand::string(10) RETURN NONE;

-- Lots of 'person' records to look through...
SELECT * FROM person WHERE name = "Billy";

-- Add an index
DEFINE INDEX name_index ON person FIELDS name;
-- The same query is much faster now
SELECT * FROM person WHERE name = "Billy";


Our database has nowhere near 25,000 records so an index for faster lookup times won't be necessary at this point. However, an index has other uses such as being able to ensure that records are unique. To do this, just add the keyword UNIQUE to the end.

One place we can use a unique index is the address field on the place table.

DEFINE INDEX unique_address ON TABLE place FIELDS address UNIQUE;
CREATE place SET
name = "Wrong house",
address = "2025 Statement Street, Riverdale",
place_type = "building";


Output
"Database index `unique_address` already contains
'2025 Statement Street, Riverdale', with record `place:surreal_library`"


A unique field can be defined on multiple fields too, such as this one defined on the in and out fields of a graph edge. This is used quite often to make sure that a RELATE statement can't be used more than once on the same two records.

DEFINE INDEX can_only_like_once ON TABLE likes FIELDS in, out UNIQUE;
RELATE person:one->likes->person:two;
RELATE person:one->likes->person:two;


Output
'Database index `can_only_like_once` already contains
[person:one, person:two], with record `likes:6lx7cqzesfh9jkic60c2`'


THE PLATFORM

Everything an application and its agents know. Five surfaces, one engine.

IN PRODUCTION

Trusted at scale. Samsung, Nvidia, Verizon, Tencent, and Walmart run on SurrealDB.

14,000+

Developers building on SurrealDB Cloud

4M+

Developers building on SurrealDB worldwide

FROM THE TEAMS

SurrealDB gives us a foundation where we can unify semantic search, knowledge graphs, and AI-driven decision making without stitching together multiple systems. Collapsing responsibility into SurrealDB has become our default engineering posture.
Justin Foley

VP of Engineering, Later

SurrealDB

The context and memory layer for AI agents

Database. Graphs, vectors, documents and relational data in one engine, in a single ACID transaction.
Agent Memory. Connects and retrieves context wherever your data lives, every fact carrying its source.
Cloud. Fully managed, in the cloud provider and region you choose.

Explore with AI

Copyright © 2026 SurrealDB Ltd. Registered in England and Wales. Company no. 13615201

Registered address: 3rd Floor 1 Ashley Road, Altrincham, Cheshire, WA14 2DT, United Kingdom

Trading address: Huckletree Oxford Circus, 213 Oxford Street, London, W1D 2LG, United Kingdom