SurrealDB Release Notes

Highlights

🧹 Remove a namespace or database of any size

REMOVE NAMESPACE and REMOVE DATABASE now delete the definition and return at once, and a background task deletes the data afterwards in batches that resume after a restart. On 2.6, removing a large database could fail with Failed to commit transaction due to a read or write conflict or never finish. Once every node runs 2.7.0, the removed data cannot be read from the moment the statement commits, and --reclaim-interval (SURREAL_RECLAIM_INTERVAL, default 60s) sets how often the task runs.

Behaviour after removal · Removal in the background

Improvements

• Changefeeds only track the databases that use them. A database that defines no changefeed no longer records a timestamp at every changefeed clean-up (every 10 seconds by default), and the timestamps it recorded on earlier 2.x releases are deleted after the upgrade.
• Background clean-up commits in batches. Changefeed clean-up and index compaction now commit 1,000 keys at a time, so a large backlog no longer runs as one transaction.
• Config::reclaim_interval in the Rust SDK sets the reclaim interval for an embedded datastore.

Bug fixes

• Fixed COUNT indexes never being compacted since they were added in 2.4.0, so a count served by the index read one entry for every record ever created or deleted on the table. The first compaction after the upgrade combines those entries.
• Fixed SHOW CHANGES ... SINCE failing with an internal error when the datetime was earlier than the first timestamp the database had recorded. It now returns the changes from the start of what is retained, and a datetime in the future returns none.

Security

2.7.0 contains no security fixes. Several advisories fixed in 3.3.0, three of them rated Critical, list every release before 3.3.0 as affected, and that includes 2.7.0. Their fixes ship in 3.3.0, and the 3.3.0 security notes list each advisory. Moving from 2.x to 3.x follows the 2.x to 3.x migration guide.

Upgrade notes

The 2.6 to 2.7 upgrade guide covers each of these in detail.

• Back up the whole datastore first if you may need to roll back. 2.6 does not know that a removal can leave data on disk, so it can serve a removed database's data again and let its users sign in. The way back to 2.6 is a backup taken before the upgrade: a storage snapshot, or an export of every database plus a record of the root and namespace-level users and access methods, which no export contains.
• Rolling upgrades. Until every node runs 2.7.0, a 2.6 node can still serve the data of a namespace or database removed on an upgraded node, so remove namespaces and databases only after the last node is upgraded.
• Reusing a removed name deletes what is left first. Defining a namespace or database under the name of one still being deleted clears up to 10,000 keys of the old data in the same transaction. If more is left, the statement fails with The name '...' cannot be reused until the data of the removed namespace or database has been reclaimed, and succeeds once the background task has caught up.
• Every removal deletes stored versions. Removing a namespace or database now deletes its version history, as AND EXPUNGE did, and AND EXPUNGE returns before the data is deleted.

UPGRADE OR INSTALL

Get SurrealDB v2.7.0

Pick how you want to install or upgrade. SurrealDB Studio can update connected instances in place, or choose a platform below to copy a CLI command for v2.7.0.

SurrealDB Cloud

You can upgrade your SurrealDB Cloud instance to v2.7.0 effortlessly through SurrealDB Studio.

1. Open the SurrealDB Studio
2. Select your organisation and instance
3. On the dashboard, click on the "Upgrade" button
4. Your instance will be updated and restarted automatically

Highlights

• 🐘 Connect with any Postgres client: Any Postgres client or driver, including psql, JDBC, npgsql and tokio-postgres, can now connect to SurrealDB and run SurrealQL or ISO GQL (Cypher Query Language) with typed results, so existing Postgres tooling works without a SurrealDB SDK. Turn the listener on with --postgres-bind. Connections support TLS and SCRAM-SHA-256 authentication, and DEFINE USER now stores a SCRAM verifier alongside the password hash, so a user whose password is set on 3.3 signs in from a Postgres client without sending it in cleartext.

• 📡 Results that stream as they are produced: Query results now stream to the client row by row instead of arriving as one buffered response, so the first rows of a large SELECT reach an application while the rest are still being produced. Streaming works over the new gRPC transport (grpc:// and grpcs://), through the new query_stream WebSocket RPC method, and in the embedded Node.js and browser engines. The surreal sql shell also connects over gRPC.

• 🕸 Faster graph traversals, and edges that carry their own data: Graph adjacency is now stored in compact blocks, so traversals over high-degree vertices and from many starting records run substantially faster, and count(->edge) is answered without loading the edges. Three new schema options keep more of a traversal inside the adjacency structure: LIGHTWEIGHT relations store nothing beyond in and out, which suits pure adjacency such as follows or likes; INLINE fields keep an edge property in the adjacency entry, so ->(likes WHERE score > 5) is answered without reading edge records; INLINE EDGES and INLINE REFERENCES cache a vertex's edges and back-links, so a low-degree lookup needs one read instead of a range scan.

• 🎯 Indexes that combine, and vector search that filters first: Index-backed conditions joined with AND, OR and NOT now combine as bitmaps, so a query that filters on several indexed fields reads only the records that match all of them, and a count() with GROUP ALL over indexed conditions can be answered without reading any records. Vector search uses the same bitmaps: WHERE conditions covered by an index become an allow-list before the HNSW or DiskANN search runs, so a filtered similarity search returns k matching results without over-fetching. EXPLAIN ANALYZE shows which plan and filter tier a query used.

• 🔒 Read-modify-write without losing an update: SELECT ... FOR UPDATE registers the records it reads for conflict detection, so a transaction that reads a record and then writes based on it fails to commit if another transaction changed that record in between, instead of silently overwriting the change. It works on every community storage backend.

• 🪪 Permissions resolved once per session, and stricter JWT checks: DEFINE ACCESS ... CONTEXT computes a value once when a record user signs in and exposes it as $session.data, so a row permission such as PERMISSIONS FOR select WHERE org IN $session.data no longer runs a subquery for every row. DEFINE ACCESS ... AUDIENCE rejects a JWT whose aud claim names a different service, even when the same identity provider issued it.

• ⚡ Faster full-text indexing, and search in Chinese, Japanese and Korean: Full-text indexes now batch their changes per transaction and key postings by document, so indexed writes run 2.3 to 2.6 times faster and updates touch fewer keys. The new SEGMENT tokenizer splits Chinese, Japanese and Korean text into words, so a search for a single word matches inside a sentence.

• 🪣 Store files in S3, Google Cloud Storage or Azure: DEFINE BUCKET in the open-source engine can now use AWS S3 and S3-compatible stores such as MinIO and Cloudflare R2, Google Cloud Storage, or Azure Blob Storage, so files managed with the file::* functions can live in object storage.

• 🔑 Pull SurrealDB Enterprise from Docker Hub (Enterprise): SurrealDB Enterprise is published as a public Docker Hub image, surrealdb/surrealdb-enterprise, so a deployment can pull it without a registry credential to provision or rotate. The image needs a licence key to run, supplied in SURREAL_LICENSE_KEY or as a file named by SURREAL_LICENSE_KEY_FILE. Each node validates its licence when it starts and every 30 minutes after that, and keeps serving for 24 hours if the licence service cannot be reached.

A 3.2 datastore upgrades in place, and 3.3.0 applies its data migrations automatically on first start. Read the 3.2 to 3.3 upgrade guide before upgrading a cluster or a deployment with vector indexes. Fixes already released in v3.2.1 to v3.2.4 are included and not repeated here.

Items tagged (Enterprise) on a heading or [Enterprise] on a bullet refer to the SurrealDB Enterprise product. Everything else applies to community.

The release also includes numerous improvements, bug fixes, security updates, and upgrade notes detailed in the full changelog.

SurrealDB 3.1.6 is a reliability rollup on the 3.1 line, backporting fixes that have already landed on the 3.2 and 3.3 lines. It fixes a batch of concurrent index-build, live-query, query-planner, GraphQL, auth, storage and configuration issues, and adds bounds on client-managed WebSocket transactions. It also backports the fix for one previously published security advisory to the 3.1 line.

The fixes are enabled by default and we recommend that all users on the 3.1 line upgrade.

Unlike earlier 3.1.x patches, v3.1.6 makes two additive on-disk format changes - a live-query cache key on the table catalog record and a checkpoint field on the index build-state record. Upgrading in place from any earlier 3.1.x release is supported and needs no action, but a node that has run v3.1.6 cannot be rolled back to an earlier 3.1.x build, and a DEFINE INDEX ... CONCURRENTLY / REBUILD INDEX should not span a mixed-version window. See Breaking changes.

v3.1.6 is a patch release with 1 security fix, 1 improvement, and 14 bug fixes on top of 3.1.5.

Security

This release backports the fix for one previously published advisory to the 3.1 line. It ships in v3.1.6 and is enabled by default.

• Malformed SurrealML file import can panic and terminate the server process (Moderate) - GHSA-jwr6-6444-28xv

Improvements

• Bounded client-managed WebSocket transactions. Transactions opened over the begin RPC that are never committed or cancelled, or left behind by an abandoned session, could tie up server resources. New per-connection and per-session caps (SURREAL_MAX_TRANSACTIONS_PER_CONNECTION and SURREAL_MAX_TRANSACTIONS_PER_SESSION, default 64 each) reject further transactions with a too_many_transactions error, and any transactions a session still holds are drained and cancelled when it detaches or resets.

Bug fixes

Indexing

• Fixed an orphaned concurrent index build never coming back after an ungraceful restart. If a node died mid-build during DEFINE INDEX ... CONCURRENTLY, the durable build state stayed in a building state, so INFO FOR INDEX reported it as indexing forever and the index never came online. A periodic engine task now adopts builds whose owner lease has expired and drives them to completion, controlled by --index-build-resume-interval / SURREAL_INDEX_BUILD_RESUME_INTERVAL (default 30s; 0 disables it).
• Fixed an interrupted concurrent index build rescanning from the beginning instead of continuing where it left off. A DEFINE INDEX ... CONCURRENTLY or REBUILD INDEX that was interrupted and later taken over restarted its scan from zero each time. The builder now checkpoints its scan cursor durably as each batch commits, so a takeover resumes from the last committed position and keeps the partial index instead of rebuilding it from scratch.
• Fixed a shutdown or memory-pressure interruption durably poisoning a concurrent index build. An interrupted build could be left in a permanent error state that also failed every subsequent write to the table. Commit coordinators now refuse commits with a shutdown error before applying, interrupted builds stay resumable at their last checkpoint, and a build in an error state queues writers rather than failing user writes.

Live queries

• Fixed live-query notifications being intermittently and persistently lost under concurrency. The live-query subscriber cache was keyed on a free-floating in-memory version bumped before commit, so a concurrent writer could cache a stale subscriber set and poison delivery from then on. The cache is now keyed on a committed timestamp written transactionally with the LIVE / KILL row, so the subscriber set a notification uses always matches the committed table state.

Query engine

• Fixed the streaming executor's FETCH ignoring computed index and key idiom parts (for example refs[0], refs[$i], or obj['key']), which silently fetched nothing instead of resolving the referenced record. It now evaluates them, matching the legacy executor.
• Fixed four idiom recursion strategies silently truncating instead of erroring on unbounded recursion. Only the default strategy raised IdiomRecursionLimitExceeded; collect, path, shortest, and repeat returned quietly truncated results. All five now error consistently, matching the legacy engine.
• Fixed the planner choosing a count-only or keys-only index strategy when the index answered only part of a multi-conjunct WHERE. An indexed COUNT over a = x AND b = y with only a indexed counted every a = x row. The optimisation is now restricted to index scans that are exact for the whole WHERE, falling back to a record scan when a residual conjunct remains.

Permissions and auth

• Fixed a DEFINE PARAM whose PERMISSIONS WHERE predicate dereferences the authenticated record (for example $auth.admin = true) failing on the streaming executor with a DatabaseEmpty error instead of evaluating the predicate, for both allowed and denied record users. The param's predicate is now evaluated with a database context, matching how a function-call permission already resolves.
• Fixed root-level bearer sign-in failing with NoSigninTarget. Root bearer access could be defined and granted (DEFINE ACCESS ... ON ROOT TYPE BEARER FOR USER) but signing in with the key was missing its dispatch arm, so it never reached the existing, unchanged root-access validation. (The client half of end-to-end root bearer sign-in ships in the SDKs.)

GraphQL

• Fixed a GraphQL mutation silently re-parsing a numeric- or time-looking string inside an object or array field as a SurrealQL literal, so "9000" became the integer 9000 and broke coercion against a TYPE string field. Such strings are now kept verbatim, while Datetime / Duration / Uuid format checks still apply.

RPC and SDKs

• Fixed commit-time transaction conflicts reaching clients as a generic error instead of the structured TransactionConflict (wire code -32009), so SDK conflict-retry helpers never fired on genuine write conflicts. The conflict kind is now preserved across every commit path (explicit BEGIN / COMMIT, USE -time commit, and implicit auto-commit).

Storage

• Fixed the TiKV backend retaining MVCC versions for roughly 1000x longer than configured, and panicking on VERSION queries. The TSO physical component was treated as microseconds rather than milliseconds, so run_mvcc_gc computed a safepoint far too far back, and packing a microsecond timestamp overflowed when converting to a version. Both now use millisecond semantics; a VERSION query against TiKV returns a clean unsupported error rather than panicking.
• Fixed the default (non-versioned) memory backend never reclaiming superseded MVCC versions and delete tombstones, so its dirty-key set grew without bound under sustained writes. The background GC worker is now wired up on the memory backend.

Configuration

• Restored human-readable size parsing for the memory_threshold Kubernetes configmap value. Suffixed values such as 256m or 1g were rejected by the configmap path (which parsed a plain integer) and logged a spurious warning, even though the environment-variable path already accepted them. Both paths now share the same suffix-aware parser. This complements the SURREAL_MEMORY_THRESHOLD environment-variable fix in v3.1.5.

Breaking changes

Unlike earlier 3.1.x patches, v3.1.6 makes two additive changes to durable on-disk records:

• The table catalog record (TableDefinition) gains a cache_lives_ts timestamp, used to key the live-query subscriber cache described above.
• The index build-state record gains a checkpoint cursor for resumable concurrent builds.

Both fields are additive and default cleanly on records written by earlier 3.1.x builds, so upgrading in place to v3.1.6 needs no action. The constraint is on going backwards: once a v3.1.6 node has written either record, an earlier 3.1.x binary cannot decode it, so downgrading to an earlier 3.1.x release is not supported after upgrading.

In addition, a DEFINE INDEX ... CONCURRENTLY or REBUILD INDEX writes the new index build-state format, so do not start or leave one running across a mixed-version window during an upgrade. If a concurrent build was interrupted by the upgrade, rebuild the index.

There are no SurrealQL syntax changes and no changes to the on-disk layout of existing record data.

SurrealDB 3.2.4 is the fourth patch release on the 3.2 line. It fixes a concurrent index build that could never finish on a table taking writes to an indexed field, and adds two bounds on write fan-out: index compaction now drains its queue in bounded batches, and a new opt-in SURREAL_TRANSACTION_MAX_WRITE_KEYS limit turns runaway fan-out into a defined, atomic failure. For SurrealDS (Enterprise), view-change messages now carry a compact record manifest with on-demand fetch, alongside three liveness fixes.

v3.2.4 contains no catalog or on-disk layout changes, so you can upgrade in place from 3.2.0 / 3.2.1 / 3.2.2 / 3.2.3. SurrealDS clusters need every node upgraded together - see Breaking changes.

v3.2.4 is a patch release with 4 improvements and 4 bug fixes on top of 3.2.3.

Improvements

• Bounded index-compaction drain: The background index-compaction cycle previously read its whole queue in one unbounded scan and deleted every entry in a single transaction, which on a large backlog could produce a transaction big enough to stall a distributed cluster. It now handles at most 10,000 entries per batch, rotates batches across indexes so one continuously-refilling index cannot starve the others, and quarantines an undecodable entry instead of wedging the drain.
• Optional write-key limit per statement: A statement's physical write count can far exceed its logical row count, since cascaded deletes, full-text term maintenance and graph-edge cleanup all multiply per-record work. The new SURREAL_TRANSACTION_MAX_WRITE_KEYS setting (default 0, disabled) caps that fan-out: once a statement transaction has buffered the configured number of writes, the next write fails with a query error naming the limit and the transaction rolls back atomically. Enforcement happens at write time rather than at commit, and covers explicit BEGIN blocks, client-owned transactions over RPC and the SDKs, and SIGNUP / SIGNIN / AUTHENTICATE clauses; internal maintenance transactions stay unbounded. Distributed deployments should pick a limit their prepare phase can absorb (50k–100k is a reasonable start); single-node and embedded deployments can leave it off.
• Compact view-change wire (Enterprise): A view change previously transferred the full record set between replicas, so its messages scaled with both record count and write-set size - large enough at scale to outlast the retry window and livelock the round. Replicas now exchange a compact per-record manifest and fetch only the records they are missing, in byte-budgeted pages (SURREAL_DS_VIEW_CHANGE_FETCH_PAGE_BYTES, default 4 MiB). At 30,000 records the leader-bound message shrinks 19.8x, or 105.9x with larger write sets, since the manifest is a constant ~52 B per record regardless of write-set volume. The live record set is now also bounded independently of wall-clock retention.
• Quieter operational logs (Enterprise): The admission-drain watchdog's error now backs off with jitter to a 60-second cap instead of repeating on a fixed 5-second cadence, and a drain that completes after escalating logs one warning with the total wait, so the episode closes. The live read-establishment catch-up's transaction-manifest collection drops from info to debug.

Bug fixes

• Fixed a concurrent index build (DEFINE INDEX … CONCURRENTLY, REBUILD INDEX) making no progress on a table that takes writes mutating an indexed field. The builder and the admitted writes contended on the same internal counter, so any write committing inside a build batch discarded that whole batch and the initial scan never committed anything. The build's ownership lease could also expire while its task was still running, leaving it open to a takeover that resumed from zero. Note that a CONCURRENTLY build or REBUILD INDEX should not be started or left running across a version change in either direction - rebuild the index if one did.

SurrealDS (Enterprise) fixes

• Read starvation after a scale-up: Fixed a node that was healthy on the current view but on a stale membership epoch having its transaction-begin requests silently dropped by its peers, so its begin quorum never formed and it served no reads while nothing knocked it out of normal operation. The re-sync that repairs the fence now has its own budget (SURREAL_DS_FENCED_RESYNC_BUDGET_MS, default 5,000 ms), and sustained unhealed fencing forces a local view change after SURREAL_DS_FENCED_VIEW_CHANGE_ESCALATION_MS (default 60,000 ms; 0 disables it).
• Forfeited backup-recovery evidence rounds: The backup coordinator's recovery evidence poll sent its request to each replica once per round with no retransmission, so a single lost datagram forfeited the round and parked the termination on a backoff ladder. The poll now retransmits to replicas that have not yet responded, within the same window.
• Stacked repair escalations: Fixed stale-tentative repair escalations piling up behind an admission drain: because the replica stays in normal operation for the whole wait, every later escalation passed the same pre-check, flooding the logs and firing a spurious recovery and view change after each completed recovery. At most one such escalation is now pending or in progress at a time, and one whose evidence was resolved while it waited stands down.

Breaking changes

• Catalog and KV on-disk layouts are unchanged from 3.2.0 / 3.2.1 / 3.2.2 / 3.2.3, so single-node and embedded deployments can upgrade in place. The item below affects SurrealDS clusters only.
• SurrealDS view-change messages changed shape (Enterprise): The compact view-change wire above uses new message variants that a pre-3.2.4 node cannot decode, so a mixed-version cluster cannot complete a view change while an upgrade is in progress. Upgrade every node together. SurrealDS has no rolling-upgrade window, so this matches the existing upgrade posture rather than adding a new constraint.

Bug fixes:

• Fixed computed fields being eagerly evaluated when not selected in SELECT queries
• Fixed $parent resolving to NONE inside graph traversal WHERE clauses
• Fixed LIMIT pushdown, plan-time parameter resolution, and computed field dependency analysis
• Fixed count() returning 1 for sets instead of counting items and added missing set function paths

Features & improvements:

• Added support for transaction conflict error reporting
• Increased v2 upgrade check frequency and added --upgrade flag for manual checks

UPGRADE OR INSTALL

Get SurrealDB v3.0.5

Pick how you want to install or upgrade. SurrealDB Studio can update connected instances in place, or choose a platform below to copy a CLI command for v3.0.5.

SurrealDB Cloud

You can upgrade your SurrealDB Cloud instance to v3.0.5 effortlessly through SurrealDB Studio.

1. Open the SurrealDB Studio
2. Select your organisation and instance
3. On the dashboard, click on the "Upgrade" button
4. Your instance will be updated and restarted automatically

Full install guide

Patches

6 patch releases on the 2.6 line.

Latest

2.6.5, released Mar 24, 2026.

Stable

Ready for production, with every patch's notes below.

Bug fixes

• Reverted the point -> geometry change

UPGRADE OR INSTALL

Get SurrealDB v2.6.5

Pick how you want to install or upgrade. SurrealDB Studio can update connected instances in place, or choose a platform below to copy a CLI command for v2.6.5.

SurrealDB Cloud upgrade steps

1. Open the SurrealDB Studio
2. Select your organisation and instance
3. On the dashboard, click on the "Upgrade" button
4. Your instance will be updated and restarted automatically

Full install guide available.

Additional patch notes for previous versions 2.6.4, 2.6.3, 2.6.2, 2.6.1, and 2.6.0 are listed with bug fixes, features, and upgrade recommendations to 2.6.5 for latest fixes and improvements.

Newer release line 3.0 updated Mar 27, 2026.

Older release line 2.5 updated Jan 22, 2026.

Features

• Added DEFER keyword for background index building and maintenance (Experimental)
• Added an auth_limit on defined APIs, functions, fields and events, that limits execution to the permissions of the creating user instead of the invoking user.

Security Advisories

• Confused Deputy Privilege Escalation through Future Fields and Functions

Note: Storable closures in future fields and functions are now disabled by default for security reasons. To enable the previous behaviour, set the SURREAL_CAPS_ALLOW_INSECURE_STORABLE_CLOSURES environment variable. This change addresses the security vulnerability described in Advisory.

UPGRADE OR INSTALL

Get SurrealDB v2.5.0

Pick how you want to install or upgrade. SurrealDB Studio can update connected instances in place, or choose a platform below to copy a CLI command for v2.5.0.

SurrealDB Cloud upgrade steps:

1. Open the SurrealDB Studio
2. Select your organisation and instance
3. On the dashboard, click on the "Upgrade" button
4. Your instance will be updated and restarted automatically

Features

• Added CONTAINS/INSIDE planning consistent with substring semantics; use indexes only for flattened or set-based operators
• Made WebSocket limits configurable
• Added 32-bit floats by default for HNSW vector indexes
• Exposed and tune RocksDB BlobDB options via environment variables
• Aligned RocksDB blob defaults with upstream and make blob compression optional
• Added configurable slow-query logging with parameter allow/deny filtering and normalised single-line output
• Added disk space limits and read-only/deletion-only modes for RocksDB
• Added notification caller when a connection is dropped
• Added COUNT Index Support with Compaction System and Enable Concurrent Index Building for WASM
• Added minimal implementation for 2.0 → 3.0 migration tool
• Ensured reverse scan is used only with compatible datastore

Bug fixes

• Fixed SELECT with SPLIT so ORDER BY and START/LIMIT apply after splitting
• Fixed OOM crash in COUNT index on large datasets by batching key retrieval
• Fixed insert ignore with unique index still creates a record when index violated

Breaking changes

• CONTAINS/INSIDE planning made consistent with substring semantics - see language test example in this file with details on using the CONTAINSANY operator with indexes

UPGRADE OR INSTALL

Get SurrealDB v2.4.0

Pick how you want to install or upgrade. SurrealDB Studio can update connected instances in place, or choose a platform below to copy a CLI command for v2.4.0.

SurrealDB Cloud upgrade instructions

1. Open the SurrealDB Studio
2. Select your organisation and instance
3. On the dashboard, click on the "Upgrade" button
4. Your instance will be updated and restarted automatically

Full install guide available.

Patches

11 patch releases on the 2.3 line.

Latest

2.3.10, released Sep 19, 2025.

Stable

Ready for production, with every patch's notes below.

Bug fixes: Fixed incorrect ORDER BY LIMIT results on multi-column index scans Fixed broken docs.rs

Bug fixes

• Fixed incorrect ORDER BY LIMIT results on multi-column index scans
• Fixed broken docs.rs

UPGRADE OR INSTALL

Get SurrealDB v2.3.10

Pick how you want to install or upgrade. SurrealDB Studio can update connected instances in place, or choose a platform below to copy a CLI command for v2.3.10.

SurrealDB Cloud

You can upgrade your SurrealDB Cloud instance to v2.3.10 effortlessly through SurrealDB Studio.

1. Open the SurrealDB Studio
2. Select your organisation and instance
3. On the dashboard, click on the "Upgrade" button
4. Your instance will be updated and restarted automatically

Full install guide

Additional patch notes for previous versions 2.3.9 through 2.3.0 are also included, detailing bug fixes, workflow improvements, security advisories, and upgrade recommendations to 2.3.10 for the latest fixes and improvements.

Notable notes from 2.3.0:

NB: We identified an issue in this release that can corrupt the database when an UPDATE statement is stored within a function. We released v2.3.1 to address this. If you defined functions with UPDATE statements in v2.3.0 please kindly remove those function definitions, upgrade to v2.3.1 and then add them back.

Features, bug fixes, workflow improvements, and deprecations are detailed across the patch releases, emphasizing stability and production readiness of the 2.3 line.

Patches.

9 patch releases on the 2.2 line.

Latest.

2.2.8, released Sep 11, 2025.

Stable.

Ready for production, with every patch's notes below.

Bug fix: Fixed Live Queries document issue Security advisories: Unauthorized Data Exposure via LIVE Query Subscriptions

RELEASED SEP 11, 2025

2.2.8

Bug fix:

• Fixed Live Queries document issue

Security advisories:

• Unauthorized Data Exposure via LIVE Query Subscriptions

UPGRADE OR INSTALL

Get SurrealDB v2.2.8

Pick how you want to install or upgrade. SurrealDB Studio can update connected instances in place, or choose a platform below to copy a CLI command for v2.2.8.

SurrealDB Cloud

You can upgrade your SurrealDB Cloud instance to v2.2.8 effortlessly through SurrealDB Studio.

1. Open the SurrealDB Studio
2. Select your organisation and instance
3. On the dashboard, click on the "Upgrade" button
4. Your instance will be updated and restarted automatically

Full install guide

Bug fixes and improvements:

• Added nu-ansi-term dependency
• Fixed Live Queries document issue

Security advisories:

• Unauthorized Data Exposure via LIVE Query Subscriptions

UPGRADE OR INSTALL

Get SurrealDB v2.1.9

Get SurrealDB v2.1.9

Pick how you want to install or upgrade. SurrealDB Studio can update connected instances in place, or choose a platform below to copy a CLI command for v2.1.9.

SurrealDB Cloud

You can upgrade your SurrealDB Cloud instance to v2.1.9 effortlessly through SurrealDB Studio.

1. Open the SurrealDB Studio
2. Select your organisation and instance
3. On the dashboard, click on the "Upgrade" button
4. Your instance will be updated and restarted automatically

Full install guide

2.1.9

Bug fixes and improvements:

• Added nu-ansi-term dependency
• Fixed Live Queries document issue

Security advisories:

• Unauthorized Data Exposure via LIVE Query Subscriptions

Bug fixes

• Check limit to string::replace with regular expressions
• Fixes long running FOR loops, adds script timeouts, improves HTTP redirect security, and optimises task yielding for better performance
• Backport JS scripting mem exhaustion fix
• Introduces Regex size limit configuration
• Improve error handling on value conversion (RPC / HTTP/SQL endpoint)
• Update rquickjs to newest version

Security advisories

• Uncaught exception in Net module leads to database crash
• Server-takeover via SurrealQL injection on backup import
• Memory exhaustion via nested functions and scripts
• Memory exhaustion via string::replace using regex
• No JavaScript script function default timeout could facilitate DoS
• CPU exhaustion via custom functions result in total DoS
• Bypass of deny-net flags via redirect results in SSRF

UPGRADE OR INSTALL

Get SurrealDB v2.0.5

Pick how you want to install or upgrade. SurrealDB Studio can update connected instances in place, or choose a platform below to copy a CLI command for v2.0.5.

SurrealDB Cloud

You can upgrade your SurrealDB Cloud instance to v2.0.5 effortlessly through SurrealDB Studio.

1. Open the SurrealDB Studio
2. Select your organisation and instance
3. On the dashboard, click on the "Upgrade" button
4. Your instance will be updated and restarted automatically

Full install guide

Patches

7 patch releases on the 1.5 line.

Latest

1.5.6, released Nov 12, 2024.

Stable

Ready for production, with every patch's notes below.

Features: Created v1, v1-dev, v1.5 and v1.5-dev Docker tags Bug fixes: Fixed an issue with object keys starting with a digit not being properly exported

RELEASED

NOV 12, 2024

1.5.6

Features

• Created v1, v1-dev, v1.5 and v1.5-dev Docker tags

Bug fixes

• Fixed an issue with object keys starting with a digit not being properly exported

UPGRADE OR INSTALL

Get SurrealDB v1.5.6

Pick how you want to install or upgrade. SurrealDB Studio can update connected instances in place, or choose a platform below to copy a CLI command for v1.5.6.

SurrealDB Cloud

You can upgrade your SurrealDB Cloud instance to v1.5.6 effortlessly through SurrealDB Studio.

1. Open the SurrealDB Studio
2. Select your organisation and instance
3. On the dashboard, click on the "Upgrade" button
4. Your instance will be updated and restarted automatically

Full install guide

Bug fixes

• Fix problems with if in identifiers after remove and define statements.
• Fix $value being NONE for DELETE events.
• Fix CBOR headers.
• Fix wrong count when using COUNT with a subquery.
• Fix IN operator should be recognised by the query planner.
• Fix response content-type on /rpc endpoint.

When using the Rust SDK, make sure surrealdb-core is up-to-date. If not, you might get back Revision errors as a result.

UPGRADE OR INSTALL

Get SurrealDB v1.4.2

Get SurrealDB v1.4.2

Pick how you want to install or upgrade. SurrealDB Studio can update connected instances in place, or choose a platform below to copy a CLI command for v1.4.2.

SurrealDB Cloud

You can upgrade your SurrealDB Cloud instance to v1.4.2 effortlessly through SurrealDB Studio.

1. Open the SurrealDB Studio
2. Select your organisation and instance
3. On the dashboard, click on the "Upgrade" button
4. Your instance will be updated and restarted automatically

Full install guide

Bug fixes

Add JWT ID claim to tokens issued by SurrealDB. Consistently enforce session expiration.

RELEASED MAR 15, 2024

1.3.1

Bug fixes

• Add JWT ID claim to tokens issued by SurrealDB.
• Consistently enforce session expiration.

UPGRADE OR INSTALL

Get SurrealDB v1.3.1

Pick how you want to install or upgrade. SurrealDB Studio can update connected instances in place, or choose a platform below to copy a CLI command for v1.3.1.

SurrealDB Cloud

You can upgrade your SurrealDB Cloud instance to v1.3.1 effortlessly through SurrealDB Studio.

1. Open the SurrealDB Studio
2. Select your organisation and instance
3. On the dashboard, click on the "Upgrade" button
4. Your instance will be updated and restarted automatically

Full install guide

RELEASED MAR 12, 2024

1.3.0

Features

• Introduced IF NOT EXISTS clause on DEFINE statements.
• Implemented IF EXISTS for additional REMOVE statements.
• Changed the KNN operator from <2> to <|2|> in the new parser and added support in the old parser for the new syntax.
• Implemented WebSocket session expiration.
• Added support for tables and geometries in CBOR.
• Added support for parsing decimal numbers with scientific notation.
• Added support for printing a warning in the CLI when using an outdated version of SurrealDB.
• Added Surreal::wait_for to make it possible for the client to wait for certain events.
• Added SurrealKV as an unstable feature.
• Added more error message improvements for the new parser.

Bug fixes

• More consistent handling of negative numbers in record IDs.
• Removed the unimplemented backup command from the CLI.
• Fixed document not being available to delete permissions clause.
• Ensured objects properties are recognised by the query planner.
• Implemented the union strategy on unique indexes.

Performance improvements

• Added compile-time feature for flamegraph and pprof profiling.

IF NOT EXISTS clause on DEFINE statements

DEFINE statements now allow you to include an IF NOT EXISTS clause which ensures that the define statement is only run if the resource doesn't already exist. If it exists, you will get an error. Learn more about this in the documentation.

New KNN syntax

The KNN operator now supports a new syntax using <| and |> instead of < and >. Learn more about this in the documentation.

Waiting for client events

It's now possible to initialise the connection and run setup actions like authentication and selecting the database concurrently with other queries by making it possible to wait for the SDK to connect or select the database to use before allowing other queries to execute.

Now it's possible to make the client wait for either the connection to be established or the database to be selected.

NEWER PATCH AVAILABLE

Upgrade to 1.3.1

You are viewing the 1.3.0 changelog. A newer patch in this release line is available - we recommend running 1.3.1 for the latest fixes and improvements.

View 1.3.1 release notes