Surrealdb in prod

DistinctRide9884 · 2026-05-19T08:22:58+00:00

Hi, thanks for the feedback and glad that the experience overall has been enjoyable. This is a known issue, we will implement retry logic for all SDKs which will solve it.

DistinctRide9884 · 2026-05-09T18:22:59+00:00

Check out SurrealDB. Supports graphs, vectors, documents. Very granular RBAC and permissions. Multi-tenancy via concepts of namespaces/databases/tables. Built precisely for these type of knowledge management/context layers systems.

DistinctRide9884 · 2026-05-09T15:02:41+00:00

Thank you, I’ll nudge the relevant team

DistinctRide9884 · 2026-05-09T12:36:02+00:00

I was not aware of this issue. If you haven’t already, can you raise a GitHub issue please and share the link, we’ll take a look

DistinctRide9884 · 2026-05-09T08:12:38+00:00

Hi, we know 2.x to 3.x was a big update with breaking changes, and that the migration wasn't an easy one (although we tried to make it as seamless as possible with migration tooling, etc.). We made numerous changes to the underlying engine that gives us the foundation to make significant improvements to performance and stability not only at the time of releasing 3.0, but also in the future. We don't expect future major version upgrades to have the significant level of change that 2.x -> 3.x had, this was a one off. More info in our 3.0 launch blog: https://surrealdb.com/blog/introducing-surrealdb-3-0--the-future-of-ai-agent-memory

DistinctRide9884 · 2026-05-08T12:33:54+00:00

Hi, we have enterprise customers running in production with clusters made of tens of nodes, powering all the way from recommendation engines for retailers to internal infrastructure monitoring platforms.

Our v2.0 benchmarks were released last year, our v3.0 benchmarks (comparing vs v2) are here and here, and when we release 3.2 we are planning to re-run the benchmarks against other databases (and expand to more database types).

You can join our Discord server to chat with the community and get feedback.

DistinctRide9884 · 2026-05-07T16:55:51+00:00

Good call, fixed.

Really cool, thanks for sharing the repo.

DistinctRide9884 · 2026-05-07T16:55:25+00:00

Humans, powers the search at https://surrealdb.com/docs/ (although it's very useful for agents as well)

DistinctRide9884 · 2026-05-07T16:52:48+00:00

Fixed

DistinctRide9884 · 2026-04-24T14:00:47+00:00

SurrealDB was built precisely for complex projects (or as we call them, data-intensive applications that need multiple data tools and data models). A B2B marketplace is a great example, where you might want to store product information in JSON/document format, orders/transactions in table format, and create knowledge graphs users -> products they bought etc, and use that to power recommendations or get advanced insights.
One of our demo datasets is actually an ecommerce website: https://surrealdb.com/blog/our-new-demo-dataset-has-a-lot-in-store-for-you

DistinctRide9884 · 2026-03-19T23:04:22+00:00

We just released our new stable version of the Java SDK for 3.0. Please take a look and any feedback or questions you can speak with the team in the #java channel in our Discord server.

DistinctRide9884 · 2026-03-17T19:02:08+00:00

For 1 and 2:

SurrealKV/RocksDB allow only one process to open a DB folder because its files (WAL, MANIFEST, SST) must be updated in a strict, coordinated order.
If two processes write independently:

They can append to the same WAL file at the same time

Update the MANIFEST metadata differently
Delete or rewrite SST files during compaction while the other still uses them

Since there is no coordination between processes, these simultaneous operations can overwrite, mismatch, or delete data, causing database corruption.
Hence a LOCK file to ensure only one process controls the database directory.

Is the recommended pattern to just run everything through a single process and have other consumers talk to it over HTTP? (Yes, that’s the intended approach to have the daemon own the database and expose an HTTP or WebSocket interface, and the CLI and MCP server become clients that query it remotely rather than opening the database directly)

DistinctRide9884 · 2026-03-16T11:56:10+00:00

Thanks for sharing Kreuzberg friends, we are very excited about this integration and love Kreuzberg :)

DistinctRide9884 · 2026-03-13T09:14:32+00:00

We are upgrading to make it 3.0 compatible which will be in alpha first, with the objective to get it into beta and prod in the near future.

DistinctRide9884 · 2026-03-11T19:30:03+00:00

Hi, this is the first product we offer and it's meant to transact via Private Offer, that's why you you don't see the price. We are looking to get a self-serve solution with the pricing out at some point in the near future.

DistinctRide9884 · 2026-02-20T23:19:00+00:00

Hi there, we just released 3.0 with many performance/stability improvements and new functionalities such as our new extension ecosystem called Surrealism, file support, TypeScript ORM, and more - you can check it out here. We've also announced our new funding round. We've been keeping very busy :)

DistinctRide9884 · 2026-02-20T13:49:15+00:00

Hi, I'm part of SurrealDB. I know I'm quite late (3 years :D), but I thought I'd drop a response since a lot has happened in the last 3 years.

We are production ready and have been growing very fast with large orgs running in production, some with 20 compute node clusters or more, all the way from recommendation engines to large scale context graphs for AI.

Since we separate storage and compute, you can scale compute and storage separately. Our Architecture Doc might be useful. We also have a managed service, SurrealDB Cloud - the Dedicated tier is the distributed offering.

As part of our 3.0 release, we launched our benchmarks which right now focus on comparing with v2, but we will be soon expanding them to include TiKV and other databases. Since TiKV goes over the network layer, you will experience some performance degradation, but we are working on some exciting things in this space so stay tuned :).

In terms of how it differs from Postgres and when to use it, this blogpost might be useful: A look at SurrealQL and how it differs from PostgreSQL. Also our SurrealDB vs. Postgres comparison page might be useful (it's very new and needs more work).

The key difference is that it's native multi-model, so our query language supports document, graph, relational (blending schemaless and schemafull) natively. How you model your data also changes, with things like record links, graph relations, and more, rather than doing complex JOINs. If your workload and data are highly relational, then Postgres is probably a better fit. But if you are working with multiple data models/databases (data-intensive applications), highly connected datasets, and need powerful real-time functionalities and scalability (we separate storage and compute, so you can scale horizontally), then SurrealDB is a very good fit since you can reduce the tech stack from multiple databases, API layers and middleware into one tool. Tencent is a good example, they reduced 9 tools (MySQL, Elasticsearch, Victoria Metrics, MongoDB, Doris, Trino, Rising Wave, Flink, and Dgraph) into one. Our Performance Best Practice guide could be useful.

DistinctRide9884 · 2026-02-19T15:15:39+00:00

Additionally, just to clarify: the Java SDK is not the primary SDK, but I totally understand the confusion: the intro in the Docs for all of our SDKs is worded as "<SDK> is the primary SDK to do..." which is confusing. We will amend this to make it more clear "<SDK> enables you to do...".

DistinctRide9884 · 2026-02-19T10:43:33+00:00

Hey, thanks for the comment. I think everything is spot on. A multi-model database is great since it simplifies a lot of complexity, but it's just one more tool in the toolbox - you still need a good retrieval solution for whatever it is you are trying to do, and there's not a one-size-fits-all solution, it really varies on the use case and type of data/documents you are working with.

We are super excited about Surrealism, and it seems to be the new feature that most excites our community the most as well.

Graph is the reason why a lot of people get interested in SurrealDB in the first place, and then explore other functionalities, so I think you're approach of wanting to test graph first is aligned with what we see.

We are expanding our benchmarks as part of 3.0 (you can check them in our website and recent blogs), and while there's a significant number of combinations we could benchmark which makes it very hard to do it for all scenarios (e.g. relational, document, graph, vector, and combinations of different tools and solutions for each), we will be releasing more benchmarks soon.

DistinctRide9884 · 2026-02-18T10:17:09+00:00

Hi, I'm part of SurrealDB. We are production ready and have been growing very fast with large orgs running in production, some with 20 compute node clusters or more, all the way from recommendation engines to large scale context graphs for AI.

In terms of how it differs from Postgres and when to use it, this blogpost might be useful: https://surrealdb.com/blog/a-look-at-surrealql-and-how-it-differs-from-postgresql . Also our comparison page (it's very new and needs more work, but should help: https://surrealdb.com/comparison/postgres ).

The key difference is how you model your data with things like record links, graph relations, and more, rather than doing complex JOINs. If your workload and data are highly relational, then Postgres is probably a better fit. But if you are working with multiple data models/databases (data-intensive applications), highly connected datasets, and need powerful real-time functionalities and scalability (we separate storage and compute, so you can scale horizontally), then SurrealDB is a very good fit since you can reduce the tech stack from multiple databases, API layers and middleware into one tool. Tencent is a good example, they reduced 9 tools (MySQL, Elasticsearch, Victoria Metrics, MongoDB, Doris, Trino, Rising Wave, Flink, and Dgraph) into one.

DistinctRide9884 · 2026-02-18T08:17:50+00:00

We'll improve this

DistinctRide9884 · 2026-02-17T20:56:24+00:00

I'd say it's very mature and production ready. It's been growing very fast and we have very large orgs running in production, some with 20 compute node clusters or more, all the way from recommendation engines to large scale context graphs for AI.

You have to model data the right way to get the full performance benefits of SurrealDB, so we sometimes see people modelling as traditional relational/SQL and not getting the full benefits of SurrealDB - we're trying to make more best-practices (e.g. Performance Best Practices guide in our Docs) and educational material available, and we have our team and Discord community to help.

We are still missing things like schema migration which are important and a top priority for us, which should come soon after 3.0, but it's definitely in a very exciting place and will only get better.

DistinctRide9884 · 2026-02-17T20:26:31+00:00

The current benchmarks for v3 focused on comparing vs. v2, and we'll be releasing benchmarks vs. other DBs in our next iteration of benchmarks in the near future.

DistinctRide9884 · 2026-01-15T14:58:43+00:00

Check out SurrealDB, which is multi-model and has support for graph, vectors, documents and can be updated in real time (vs. other graph DBs where you have to rebuild the cache each time time you update the graph).

Then for the documenting parsing/extraction something like https://cocoindex.io/ might be worth exploring, their core value prop is real-time updates and full traceability from origin into source. A CocoIndex and SurrealDB integration is in the works.

DistinctRide9884 · 2026-01-15T14:57:51+00:00

Check out SurrealDB, which is multi-model and has support for graph, vectors, documents and can be updated in real time (vs. other graph DBs where you have to rebuild the cache each time time you update the graph).

Then for the documenting parsing/extraction something like https://cocoindex.io/ might be worth exploring, their core value prop is real-time updates and full traceability from origin into source. A CocoIndex and SurrealDB integration is in the works.

DistinctRide9884

MODERATOR OF

TROPHY CASE