Does the combined data model justify a switch?
SurrealDB combines document records and graph relationships in one database. Its README demonstrates directed edges between a user and an article, typed fields, unique indexes, and queries that traverse relationships. Consider it when those capabilities could replace separate representations or synchronization code in your application. That benefit remains something to establish with your own model.
SurrealQL is a language commitment. The examples use record identifiers and arrow-based graph traversal alongside familiar SELECT syntax. Translate a representative application query, including its access rules, before choosing the database. Check whether the result removes code you currently maintain and whether your team accepts the query language. The supplied README provides modeling examples, but those examples were not executed in this review.
What happened when we ran it
Our SurrealDB source build and test commands each timed out after 900 seconds. Dependency installation succeeded in 47 seconds, with 743 dependencies recorded. The October 4, 2026 run checked out commit 18971ff in a sandbox configured with 3 CPUs, 12 GB of RAM, and image lab-rust:1.
The checkout contained 4,297 files, roughly 506,903 source lines, and 28.8 MB of files. The scan recorded 19 CI workflow files and a tests directory, with no Dockerfile detected. These describe the checkout and source workflow, not database performance or successful upstream checks.
The final test-log lines were compilation output for dependencies including regex, async-graphql, and wasm-opt-sys. They also showed surrealdb-types v3.3.0-nightly inside the checkout. That package label does not identify a tested server release. The log tail contains no completed test result and establishes no cause for the timeouts. The image label does not establish the actual compiler or operating-system version.
This run leaves query speed, recovery behavior, authorization behavior, and published-binary setup unassessed. Neither timeout identifies a failed database assertion or proves that the database is broken.
Keep the development example separate from deployment checks
The README documents Homebrew, platform-specific scripts, and Docker. Its in-memory Docker development example supplies a root username and password. Those are documented entry paths; this review did not reproduce them or measure their installation time.
For an application trial, choose the intended storage configuration and application credentials. Create representative records, restart the deployment, and check persistence and access rules. These are proposed acceptance checks, not results from our sandbox. A successful root query would not establish what an ordinary account can read or change.
Direct browser access puts permissions in the database
The README documents row-level permissions and direct browser queries over WebSockets. Evaluate that architecture when database rules could replace API handlers your application currently needs. The review did not test whether any particular permission rule enforces an application's requirements.
Use unauthorized reads and writes as acceptance cases: create a record owned by one account and attempt access through another account. Include graph relationships and live subscriptions if the application uses them. Teams keeping authorization in an existing service should assess the document and graph model separately from the proposed benefit of direct client access.
Resolve licensing and documentation uncertainty
The supplied core license is Business Source License 1.1. It explicitly says it is not an Open Source license. Its additional-use grant prohibits use as a defined Database Service: an offering that provides database functionality to third parties, other than direct employees or contractors working on your behalf, and enables those third parties to create, manage, or control schemas or tables. Read the core license for the version you intend to deploy before committing to that offering. The supplied license names its Licensed Work as SurrealDB 3.0; this review does not establish the license contents at commit 18971ff.
Documentation receives 3/5 on a reading-only rubric: 1 means no usable entry instructions, 3 means setup recipes and worked modeling examples are present, and 5 requires verified operating guidance. The supplied README meets the middle criterion. This score does not certify that its commands work or assess the linked manuals.
The supplied README describes GraphQL as supported in one passage and coming soon in another. Treat its availability as unresolved by this evidence and verify it for the intended version if required.
Community responsiveness remains unassessed. Supplied metadata records a last push on October 19, 2026, but does not establish response times or support quality.
Compare the model with PostgreSQL and ArangoDB
PostgreSQL's README documents SQL transactions and foreign keys. Start there when relational constraints cover the application and adopting SurrealQL would add work without removing an existing burden.
ArangoDB's README documents native graphs, JSON documents, integrated search, and AQL. Compare it when a combined document-and-graph model is central to the decision. Neither comparison establishes relative performance, reliability, or setup effort; this review ran no shared workload across the databases.
Prototype SurrealDB with a difficult query and its permission rules. Check persistence and recovery using the intended deployment, and resolve the applicable license. Choose it only if the combined model provides a concrete benefit your team can demonstrate. Our source run leaves build and test completion at commit 18971ff unverified.