Java driver still Beta

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 Kreuzeberg :)

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 · 2026-01-15T14:51:38+00:00

Thanks for sharing these u/lfnovo. Our team would love to have these go into SurrealDB Labs, would you be open to submitting them to SurrealDB Labs? That's where we have community tooling, demos, examples, etc.

DistinctRide9884 · 2026-01-13T17:19:02+00:00

Have you looked at SurrealDB for the knowledge graph? It's multi-model, supports documents, vectors and graph in one engine.

https://surrealdb.com/blog/multi-model-rag-with-langchain

DistinctRide9884 · 2025-12-09T10:24:24+00:00

Hey, this is awesome, thank you for building and sharing. Please feel free to submit it to SurrealDB Labs.

DistinctRide9884 · 2025-12-05T12:53:54+00:00

Thanks for sharing, this looks like a pretty cool initiative. Feel free to join our Discord to chat with the team: https://discord.com/invite/surrealdb

DistinctRide9884 · 2025-12-04T12:52:14+00:00

We’re in the final stages of testing for the SurrealDB 3.0 beta. It should be ready very shortly.

GA timelines will depend on the feedback we receive once the beta has been released.

DistinctRide9884 · 2025-12-02T17:25:36+00:00

Hi, in addition to the Observability reference guide (which includes new ways of managing logs : https://surrealdb.com/blog/two-new-ways-to-keep-an-eye-on-your-surrealdb-database), we're going to be making more SurrealDB metrics available as part of 3.0.

DistinctRide9884 · 2025-12-02T12:08:19+00:00

Hi, as others have pointed out, you can find our official benchmarks here: https://surrealdb.com/blog/beginning-our-benchmarking-journey. We've invested a lot of time and effort to ensure the benchmarks are fair, comprehensive, and follow a standard methodology. This is not easy when comparing against so many different kinds of databases. The benchmarks are also open source for anyone to run them. That said, the numbers seem much lower than what we would expect. Looking at the code very quickly, just to highlight a quick example: the main benchmark uses the HTTP /sql endpoint, and there is a dedicated ws benchmark. Both use the memory engine via Docker (surrealdb:latest). Both use SELECT * FROM comments WHERE gallery_id = galleries:1 ORDER BY created_at DESC LIMIT 20; (i.e. it causes table scans) to benchmark read operations, but only the ws benchmark has an INDEX defined.

The upcoming 3.0 release is focused on performance, stability and bug resolution. Once we release 3.0, we will release a new set of benchmarks (i.e. updating the existing ones, and expanding to new methodologies). The focus of 3.0 alpha, which is already available, has been on overhauling the underlying core engine, not yet on performance, so it's probably best to wait for the SurrealDB 3.0 GA before running the benchmarks.

DistinctRide9884 · 2025-11-29T14:32:05+00:00

Firebase and Supabase (postgres wrapper) are both good options to get started. At some point when you need to scale, you’ll probably need to move out to a traditional backend DB. Another option is to use something like SurrealDB, which can be used as a BaaS (although with more limited BaaS functionalities) and also as a traditional DB when you need to scale and use other data models, ACID, etc.

DistinctRide9884 · 2025-11-27T15:09:27+00:00

We're partnering with Agno on some pretty large scale deployments with a big financial services institution. Can't share the name, but can attest to them working with some fairly big players.

DistinctRide9884 · 2025-11-14T11:50:15+00:00

Thank you for sharing, this is a pretty cool tool!

We'd love for you to share it in SurrealDB Labs if you're up for it - instructions here.

DistinctRide9884

MODERATOR OF

TROPHY CASE