SurrealDB vs.
Elasticsearch

Q: How does vector search compare between the two?

Both use HNSW indexes. In Elasticsearch, kNN runs through the search API against synced copies of the data; in SurrealDB, vector similarity is a SurrealQL expression that combines with BM25 scores, graph traversal and filters in one statement over current data.

Q: What does migrating from Elasticsearch to SurrealDB involve?

Four steps: export documents with the scroll or point-in-time API and bulk-insert them; translate mappings into DEFINE TABLE and DEFINE FIELD; recreate analysers and search settings as DEFINE ANALYZER and DEFINE INDEX; port Query DSL to SurrealQL. Teams run both in parallel until results match, then cut over.

Q: How does on-prem pricing compare?

Elasticsearch gates advanced security, machine learning and platform features behind paid self-managed tiers priced per node. The SurrealDB engine is source-available under BSL 1.1 and free to self-host with every feature included, air-gapped environments included; enterprise support and the managed cloud are optional.

Q: When is Elasticsearch the better choice?

Centralised log analytics or observability at very large ingest volumes, with dashboards and alerting on Kibana and the Elastic ecosystem. SurrealDB's advantage is application search, where the documents searched are also the operational data read, written, related and secured.

Try SurrealDB Contact us

Elasticsearch. A search cluster run beside your database.

SurrealDB. Full-text and vector search built into the database itself.

One engine. One query language, with ACID consistency across it.

01 |THE DIFFERENCE

Where Elasticsearch is synced into, SurrealDB searches the source

Elasticsearch is a search layer that data is synced into. SurrealDB makes search an index on the transactional data, so relevance, freshness and consistency come from one system.

Search on the data itself

Elasticsearch is a search layer that data is copied into through an ingest pipeline. In SurrealDB, full-text and vector search are index types on the transactional records, with nothing to sync.

Explore full-text search

CONSISTENCY

Results that reflect committed data

Elasticsearch has no multi-document transactions, and search reflects writes only after an index refresh. SurrealDB is ACID with read-your-writes, so a search never trails the source of truth.

Explore transactions

OPERATIONS

One binary, no cluster to tune

Elasticsearch is a JVM cluster with heap tuning, shard sizing and rebalancing as routine work. SurrealDB is a single Rust binary that runs embedded, single-node or clustered without shard planning.

Explore deployment

02 |THE SAME QUERY

How SurrealDB and Elasticsearch differ

A search cluster beside the primary database means an ingest pipeline to build and reconcile, and results that lag the source of truth.

SurrealDB

Elasticsearch

Full-text search

Native BM25Native BM25 full-text with custom analysers and highlighting, queried in SurrealQL alongside every other data model.

Native BM25Mature BM25 full-text with analysers and highlighting - its core strength.

Vector search

Native HNSWNative HNSW vector indexes, combined with keyword scores, graph traversal, and structured predicates in one statement.

dense_vectordense_vector fields with HNSW-based kNN, queried through the search API.

Relationships

First-classRecord links and native graph traversal with typed, queryable edges - relationships are first-class.

EmulatedNo general-purpose joins or graph traversal. Nested documents, parent-child mappings, and limited ES|QL lookup joins emulate relationships, with well-known performance costs.

Consistency and freshness

Consistency and transactions

ACIDACID transactions with read-your-writes - search results always reflect committed data.

Near-real-timeNo multi-document ACID transactions. Single-document reads are realtime, but search only reflects writes after an index refresh.

Live updates

Live queriesNative live queries stream result changes to clients over WebSocket.

PollingNo push-based query subscriptions - clients poll for changes.

Operations and cost

Role in the stack

Primary databaseThe primary database. Full-text and vector search are index types on the transactional data itself - nothing to sync.

Secondary layerA secondary search layer. Data is copied in from a primary database through an ingest pipeline you build and monitor.

Architecture

One binaryMulti-model database in a single Rust binary, with compute-storage separation for distributed deployments.

JVM clusterLucene-based distributed search cluster on the JVM. Data lives in index shards that operators size, allocate, and rebalance.

Query language

SurrealQLOne SQL-like language - SurrealQL - across every model, plus SDKs, REST, WebSocket, and live queries.

Query DSL and ES|QLJSON Query DSL plus ES|QL for search and aggregations, with administration through separate REST APIs.

Operations

No shard planningSingle binary, no JVM. Runs embedded, single-node, or clustered without manual shard planning.

TuningJVM heap tuning, shard sizing, index lifecycle management, and cluster rebalancing as routine operator work.

Security and permissions

IncludedRecord-level permissions defined in the schema and enforced by the engine - included in the source-available core.

Paid tiersTLS and role-based access in the free tier; document-level and field-level security sit in paid subscription tiers.

On-prem pricing and licensing

Source-availableSource-available engine under BSL 1.1, free to self-host with every feature included. Paid support and managed cloud are optional.

TieredFree Basic tier with advanced features gated behind paid self-managed subscription tiers, priced per node and negotiated with sales.

04 |MIGRATION

Moving off Elasticsearch. Export, translate the mappings, port the queries, then cut over.

Search is an index definition

Export documents with the scroll or point-in-time API and bulk-insert them; translate mappings into table and field definitions; recreate analysers and indexes; port Query DSL to SurrealQL. Most teams run both in parallel until results match, then cut over. Talk to us about a migration workshop.

-- Search is an index definition, not a second system
DEFINE ANALYZER report_text
    TOKENIZERS class
    FILTERS lowercase, snowball(english);
DEFINE INDEX report_search ON report
    FIELDS content
    FULLTEXT ANALYZER report_text BM25 HIGHLIGHTS;
DEFINE INDEX report_vectors ON report
    FIELDS embedding
    HNSW DIMENSION 768;

-- Hybrid retrieval: keyword relevance and vector similarity
LET $q = "credential stuffing incident reports";
LET $vec = fn::embed($q);

-- Vector
LET $vec_results = SELECT id, title,
    (1 - vector::distance::knn()) as vec_score
FROM report
WHERE embedding <|10,40|> $vec;

-- BM25
LET $bm25_results = SELECT id, title, content,
    search::score(1) as bm25_score
FROM report
WHERE content @1@ $q ORDER BY bm25_score DESC;

-- Re-ranking
search::rrf([$bm25_results, $vec_results], 10);

TRUSTED BY

Enterprise teams building on SurrealDB

See all case studies

Three data stores collapsed into one

An AI assistant for 10,000 technicians

Nine backend tools consolidated into one

Low-latency RAG, under the customer's control

45 million recommendation queries a month

Elasticsearch,answered

Can SurrealDB replace Elasticsearch for full-text search?

For application and product search, yes: native BM25 with custom analysers, tokenisers, filters and highlighting, defined as indexes on transactional tables, so results reflect committed writes. For petabyte-scale log analytics built around Kibana, Elasticsearch remains a strong fit.

How does vector search compare between the two?

What does migrating from Elasticsearch to SurrealDB involve?

How does on-prem pricing compare?

When is Elasticsearch the better choice?

THE PLATFORM

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

Database

Document, graph, vector, time-series and relational in one engine.

Five data models as dotted tiles: documents, graph, vector, time-series and relational

Agent Memory

What an agent learns, with its source and its time, in the same engine.

A timeline of remembered facts, each with its source

Cloud

Managed clusters in the regions you choose, scaled on demand.

Clusters in three regions on a world map, each running or scaling

Studio

Query, explore and design the schema from the browser.

MCP

Every model that speaks MCP reaches the database and the memory directly.

Three models connected through MCP to the database and Agent Memory

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

GET STARTED

Evaluate SurrealDB against Elasticsearch. Full-text, vector, graph and structured data in one consistent engine.

Start free with SurrealDB Talk to us

SurrealDB vs. Elasticsearch