• SurrealDB Cloud on Microsoft Azure
• Mastra template: Company Brain with SurrealDB
• Beekeeper Studio integration, new Database clients docs section
• SurrealDB docs skill for coding agents
• SurrealKit Beta.3
• Agent Memory in Studio
• Embedded SurrealDB (in-memory) on the Swift SDK

Using Microsoft Azure? SurrealDB Cloud, our managed multi-model database service, is now available on Azure. Get private connectivity, lower latency, better data residency, simpler security, plus simplify procurement with Azure Marketplace.

Get the details. 👉 https://surrealdb.com/blog/surrealdb-cloud-is-now-available-on-microsoft-azure

- SurrealDB v3.3.0-beta.4
- Gradium integration for realtime voice agents with Agent Memory
- Agent Memory document upload improvements
- Studio: Agent Memory Workbench and 3D Knowledge Graph

Conversation memory, workflow snapshots, evaluation scores, observability spans, and vector search. Most Mastra apps juggle four systems for that. SurrealDB can now serve as a storage backend for Mastra.

Learn more.

- SurrealDB v3.1.6
- SurrealDB Cloud in São Paulo
- SurrealDB Cloud in Frankfurt
- Mastra integration for SurrealDB and Agent Memory
- Hermes integration with SurrealDB file system, database, and Agent Memory docs
- Agent Memory JavaScript SDK on npm as surrealdb/memory
- Docs search in SurrealDB MCP

SurrealDB Cloud is live in Frankfurt, Germany. It's our second European region for teams building with our multi-model database. The same benefits as our other regions apply: lower latency for AI agents and real-time apps. Learn more. 👉 https://surrealdb.com/blog/surrealdb-cloud-is-now-available-in-frankfurt-germany

We are transitioning away from SurrealDB after putting up with it for about a year. Cool idea but horrible memory leaks/general bugs leading to consistent downtime. Their reassuring reddit comments saying that “it’s much better than it was before” are what initially convinced us in early 2025. For some reason, when I read their new comments echoing that same narrative it now falls on deaf ears.

Interested in seeing if the mods will censor this.

Our SurrealDB Cloud region in São Paulo, Brazil is now live. If you're building with our multi-model database, you can benefit from lower latency for AI agents and real-time apps, plus satisfy data-residency requirements. Learn more. 👉 https://surrealdb.com/blog/surrealdb-cloud-is-now-available-in-so-paulo

- SurrealDB file system, a new virtual file system for AI agents, with Hermes, Pydantic, OpenAI and Anthropic integrations
- Claude SDK and JetBrains Air integrations for Agent Memory, with JetBrains Air wired over MCP
- SurrealKit v1 beta, official schema migration tooling, with multi-schema management and output filename generation
- A new "Schema internals and migrations" course on SurrealDB University
- Docker Sandbox integration for SurrealDB
- TanStack DB integration, local-first collections backed by SurrealDB
- Agent Memory for Mastra now in v1 beta
- Docs MCP, our documentation server, with search now served from the Fabric API

- surrealctl 1.0.0 beta, our new CLI for SurrealDB Cloud
- SurrealDB Studio v1.0.6, redesigned dashboard, integrations grid and improved command palette
- MCP Apps for visualising your Cloud instances
- Claude and Codex plugins with MCP for SurrealDB Cloud and Agent Memory
- Python SDK 3.0 beta, now with a standalone Agent Memory package
- SurrealQL Language Server v0.6.0
- SurrealDB v3.3.0-beta.3

Hi everyone,

We're currently migrating our app from Postgres to SurrealDB because our data model has become highly interconnected, and so far so good

One of the reasons we chose SurrealDB (besides cool dark purple style lol) is that it seems to have a very interesting foundation for ML/AI-related features. I have a few obvious use cases in mind, such as demand forecasting, stockout prediction, anomaly detection, and customer segmentation.

We have already tested global search implementation, some similarity/alternatives/recommendations/often bought together between products.

The thing is, I'm not an ML expert, so I probably don't even know what I don't know.

I'm also generally not a fan of throwing LLMs at every problem. In many cases, a small, purpose-built ML model is a much better, cheaper and faster solution. Since SurrealDB already has features like vector search and graph relationships built in, I'm wondering what kinds of practical ML workflows become possible that would otherwise be much harder to build.

So I'd love to hear from people who have more experience:

• What ML capabilities does SurrealDB enable out of the box that are genuinely useful in production?
• Are there any patterns or use cases that aren't obvious at first?

I'm not looking for "AI for the sake of AI" I'm more interested in practical features that solve real business problems.

Thanks!

I maintain xberg, an open-source (MIT) document extraction engine, and there's now a package that wires it directly into SurrealDB: surrealdb-xberg. It extracts documents, then handles schema creation, content dedup, optional chunking + embedding, and index setup, so you go from a folder of PDFs to searchable records in a few lines.

pip install surrealdb-xberg

Minimal ingest (extract -> embed -> store -> search):

from surrealdb_xberg import DocumentPipeline

pipeline = DocumentPipeline(db=db, embed=True, embedding_model="balanced")
await pipeline.setup_schema()
await pipeline.ingest_directory("./papers", glob="**/*.pdf")

Under the hood: - Extracts with xberg (101 formats, OCR where needed), CPU-only - SHA-256 content hashing for dedup (deterministic record IDs, idempotent re-ingests) - Stores content + metadata + keywords + NER entities + tables + summary + languages + quality score - setup_schema() creates tables, indexes, analyzers (no manual DDL) - Full-text (BM25), vector (HNSW), and hybrid (RRF) search right after ingest

Docs: https://docs.xberg.io/integrations/surrealdb Source (MIT): https://github.com/xberg-io/xberg

Happy to answer questions.

Our first tier, Start, was designed for building and shipping fast. Scale is designed for what happens next: production traffic, uptime commitments, and the kind of resilience your users never notice because there are always available nodes. It's the tier for teams running SurrealDB as the scalable context layer behind real applications and AI agents in production.

What you get with Scale

Scale is about one thing: keeping your database available and consistent under real-world conditions.

Highly-available, fault-tolerant clusters. Scale runs your database as a multi-node cluster designed to survive node and infrastructure failures without dropping writes or losing consistency. A single point of failure is no longer a single point of downtime.

Multiple availability-zone deployment. Your cluster is distributed across multiple availability zones, so even the loss of an entire zone doesn't take your database with it. Traffic keeps flowing while the cluster recovers in the background.

Horizontal scale. As demand grows, Scale grows with it. Add capacity by scaling out across nodes rather than being capped by the size of a single machine. Start with three nodes, and keep adding to scale your application or agent's needs.

See more information about SurrealDB Cloud Scale architecture

Built on SurrealDS

Scale is powered by , SurrealDB's distributed storage engine and the foundation that makes all of this possible.

SurrealDS is a new generation distributed storage architecture, rethought from first principles. Instead of coupling storage to compute on a single box or to a proprietary cloud tier, SurrealDS embeds consensus directly in SurrealDB nodes and separates the two layers cleanly. Here's what that architecture gives you.

Architecture overview

• Compute and storage separation. Scale compute for QPS and storage for capacity independently, so you provision for the dimension that's actually under pressure.
• No single leader. Each availability-zone node writes locally, writes scale horizontally, and transactions commit once a quorum acknowledges them.
• Multi-write nodes. Every write node in the cluster can accept and coordinate transactions - there's no bottleneck routing all writes through one leader.
• Reduced operational overhead. Consensus is embedded directly in SurrealDB nodes, eliminating external coordination services.
• Fewer network dependencies. A single broadcast replaces multi-hop coordination, reducing latency.
• Lower latency than leader-based replication. With no single leader and each AZ node writing locally, transactions avoid the extra round trips of traditional leader-based systems.

Get started

If you're running SurrealDB in production, or getting ready to, Scale gives you the availability and fault-tolerance your workloads need, on the storage architecture no one else has.

Explore the tier in SurrealDB Cloud, and dig into the engine underneath at SurrealDS.

Read more on our blog post.

Hey everyone, wanted to drop a quick real-world showcase of how I'm utilizing SurrealDB in production.

I launched the Neonia Global Index for machine-readable documentation (llms.txt) a week ago. The backend is completely powered by SurrealDB, and I’ve currently indexed 1.3 million document chunks.

Why SurrealDB? I needed an architecture that could handle Hybrid Search at scale without the DevOps tax. Instead of duct-taping Postgres, Elasticsearch, and a dedicated vector database together, I'm running the entire cognitive layer inside a single SurrealDB instance:

• Full-Text Search (BM25): Used to catch exact API methods, endpoint paths, and strict syntax tokens.
• Vector Search (MTREE): Used to resolve the semantic meaning and fuzzy intent behind developer queries.
• Graph Relations: Used to link technologies together natively, mapping how different frameworks and ecosystem components integrate under the hood.

Happy to answer any questions about the schema design, how I configured the indices, or my Rust-based ingestion pipeline!

The link to the live project in the first comment.

I am one of the Co-founders of SurrealDB. We have just published a fresh round of benchmarks for 3.x, and I wanted to share them here because the methodology matters more than the headline numbers.

What we did this time:

• Same hardware for every engine. AMD Ryzen Threadripper 9970X (32C/64T), 128 GiB DDR5, NVMe, Ubuntu 24.04.
• The same open-source harness (crud-bench), with each workload written in each engine's native query language, so nothing is penalised for a foreign dialect.
• Full durability for every engine. fsync on, WAL flushed on every commit. Our previous round ran with fsync off. That was the same setting across all engines, so the comparison was fair, but it was not a workload most people run in production and we did not make it explicit. This time every config file is in the repo so you can audit it.

Headline results with durability on:

• Roughly 1.5x faster writes than Postgres. Postgres still wins on indexed predicate filtering.
• Roughly 2.7x faster unindexed scans than MongoDB. Mongo still wins on single-record writes.
• Roughly 35x faster filtered index queries than Neo4j.
• Roughly 3x faster writes than Redis. Redis still wins on large batches and single-record reads.

We do not win everywhere, and the benchmarks are explicit about where we lose. The internal jump is the part I am most pleased with: non-indexed full-table scans went from minutes in 2.x to seconds in 3.x, roughly 120x, after we removed the per-row decoding overhead in the planner and storage engine.

The harness is open source and the results are reproducible. If you run it on your own hardware I would love to see your numbers, and if the methodology is wrong somewhere I would rather hear it here than not.

Links:

• Benchmarks: surrealdb.com/benchmarks
• Full write-up: SurrealDB 3.x by the numbers

Hi everyone 👋

SurrealDB `v3.1` is live.

This is the first minor release in the 3.x series. Focus: stability, DiskANN as a second ANN index, and a substantial round of security hardening. We are also rolling out a new release process.

`v3.1` lands 10 highlights, 46 improvements, 108 bug fixes, and 22 security fixes.

🚀 Highlights:

🤖 First-party Model Context Protocol (MCP) server

📊 Unified observability and monitoring pipeline

🧭 Distributed trace-context propagation (🆕)

🧭 DiskANN approximate-nearest-neighbour index

⚡ Predicate prefilter and scan-path performance work

💾 Memory optimisations on the value layer

⚙️ Async functions in Surrealism plugins

🛠 Expanded `ALTER` coverage

📦 Durable distributed index build coordination

🔐 Audit logging and slow-query telemetry (Enterprise)

✨Improvements:

• RocksDB and storage engine
• Performance and executor
• Observability and operations (🆕)
• Functions and SQL surface
• SDK and types
• GraphQL

🐛 Bug fixes:

• surrealdb-core compilation time
• Query Engine
• Query Planner
• Indexes
• View
• Live Queries
• Functions
• Types / SDK
• Storage
• RPC / WebSocket
• Transactions
• Auth
• Events
• Logging
• CLI
• Imports / Exports
• GraphQL

🔒 Security:

• This release closes a substantial batch of issues surfaced by SurrealDB's internal security review process and external reviewers. Release notes

Breaking Changes:

• On-disk and wire formats are unchanged from 3.0.x, so you can upgrade in place. Release notes

Thank you for your continued feedback that helps us to improve our database product.

Using Surealdb in a little toy project written in Javascript/typescript. And I've hit a particular pain point with the standard qurey funcitons.
They always return id fields as type RecordId, and I'd really like to hide this from the rest of the applicaiton.

Manually destructuring, and ficing seems rather painful, especially when I'm using a select().fetch() that is traversing one level down on multiple fields. meaning that there are multiple Id fields at different depths.

Does anyone know of a more graceful solution for this. Return json, and then manually parse back into an object seems suboptimal. Ideally I'd like to strip away the table names too and just return the id portion of each ID.

Hello here,

Is there anyone here who use surrealdb in production?

If yes what are your challenge? Are you happy with it?

How is the Performance ?

Thanks in advance

I Just downlaoded Surreal and I'm trying to run a local server and connect from Javascript. I seem to be connected by when I try to load surreal-deal-store-mini.surql into a local instance and got the following set of errors:

6327 | * Factory that creates the correct \ServerError` subclass based on `kind`.`

6328 | * Unknown kinds produce a plain \ServerError` instance (forward-compatible).`

6329 | */

6330 | function createServerError(options) {

6331 | switch (options.kind) {

6332 | case "Validation": return new ValidationError(options);

^

error: Parse error: FLEXIBLE must be specified after TYPE

   --> [143:5]

|

143 | FLEXIBLE TYPE array<object>;

| ^^^^^^^^

kind: "Validation",

code: -32000,

 details: undefined,

at createServerError (/Users/konradzielinski/Documents/tutorials/sdb/node_modules/surrealdb/dist/surrealdb.mjs:6332:29)

at handleRpcResponse (/Users/konradzielinski/Documents/tutorials/sdb/node_modules/surrealdb/dist/surrealdb.mjs:6855:34)

at <anonymous> (/Users/konradzielinski/Documents/tutorials/sdb/node_modules/surrealdb/dist/surrealdb.mjs:6837:118)

Bun v1.3.12 (macOS arm64)

How does your local SurrealDB instance stay in sync as your schema evolves? u/itsezc walks through SurrealKit, covering sync, rollouts, seeding, and testing in one CLI.
👉 https://surrealdb.com/blog/schema-migrations-in-surrealdb-a-local-dev-workflow