SurrealDB wants to be the future of SQL

Out with the old geezer SQL. In the new way to use a database.

The big news some weeks ago was SurrealDB reaching a relative stable version 1.0 and beta public release. At time of writing this is still on beta, and there are some features and documentation missing, but given what the guys behind SurrealDB promised (and delivered), seems like the age of traditional SQL databases is may be coming to a close.

I say “may be coming to a close” lightly. Currently, traditional SQL databases still sit behind the app serving data, being so battle-tested and reliant. Nobody thinks that an user should have access to the database itself. However, it’s evident that these are a nuance to play with outside their intended use. The web as moved so quickly, it has already past that point.

While everything supports SQL, fine-tuning and management is also nightmare. It’s not possible, or more difficult that it seems, to connect to a database with Javascript, let alone open it to the wild Internet. That’s what SurrealDB wants to change.

The things that I like from my first impressions of SurrealDB is that is not bound to be just backend service. It seems that it can become a single tool that can solve two or three problems in very simple ways.

A quick look at the documentation explains it all: SurrealDB is a NoSQL-focused database written in Rust, but can become a strict database, and even live in the system memory alone.

The difference between other solutions? No more proprietary protocols or system drivers, HTTP and WebSockets is all you need.

Move aside SQL!

SurrealDB gives the impression to be a jack of all trades. While the focus is on being a schemaless database by default, its language is reminiscent of classic SQL, with their own flavor of syntax added on top. Compared to the traditional standard, feels more modern and straight, and less cumbersome to learn.

The other thing that’s cool compared to old SQL databases is that it can make tables schemaless to schemafull. There is support for indexes, unique indexes, and promises to implement Full-Text indexing in the future — even then, I still think Mailisearch is the winner here. If that’s is not your cup of tea, SurrealDB can still work as a key-value store, much like memcached or Redis, sitting in memory and limited to what the host provides.

$> surreal start memory

There are a lot of features, both completed and planned, that makes SurrealDB an excellent choice to start working with because, even if some of the features are not new in the SQL space, these are very easy to understand and implement.

• Authorization can be bound to records in the database, and can be scoped to tables, rows and fields, and actions (like updates or deletions).
• It exposes an HTTP REST endpoint and WebSockets (currently not documented but I can infer how it works nonetheless).
• Combine that with a frontend app and a browser can directly query the database without risks.
• You can define “events” on tables, that can see the value before and after the change of a row when a condition triggers it.
• There is a lot of functions available at query time, from simple time and validation to geolocation and HTTP requests for easy Webhooks. You can even embed Javascript functions inside any statement.
• Let me repeat that: You can even embed Javascript functions inside any statement.

One thing missing, but being worked on the Rust version of SurrealDB, is subscribing to live queries. These work like your usual pub/sub, but you receive all records that match the query.

As an alternative, there is a promise to implement GraphQL Subscriptions.

I’m still baffled that SurrealDB exists at all in the way it does, and I’m probably scratching the surface, but it seems that it could become the next big thing on databases if we consider all the nuances that have plagued SQL for the last decades.

Still, the are four problems on top of SurrealDB that opaques its future of broad implementation.

1. It’s not battle-tested

The first indication of how a product may be good enough is to check who are using it, and how.

There are no blog posts or media (at time of writing) that talk about implementation or “success stories”, which the tech bosses like to hear before accepting an alternative or green light a project. There is no big project using it, let alone one with high success.

Also, changing a database from traditional SQL to SurrealDB overnight is impossible, which opens the next point.

2. There is no migration path

By now all major projects run over a traditional SQL database, or they are heavily married to other database engines like MongoDB. There is no clear “migration” pipeline to move data from any of these database system to SurrealDB.

For most projects, changing raw queries is prohibitive, and if the SQL database works, then it’s difficult to push for a change for something that is relatively new in the data space.

3. There are no performance metrics

You may say that SurrealDB feels like a slap in the face to other SQL engines out there, but while the syntax and convenience is there, what’s not is the talks about performance.

Since there are no performance comparisons, it’s kind of difficult to make decisions on serious projects if there are no guarantees that it won’t perform better or worse. What if query relations are slower? What if indexes don’t add performance? What if the RPC is slower than REST? How it handles transactions? And so on…

There is also the big question of tuning. For example, it’s known that RDBMS can change engines for write-heavy scenarios, like a message board, or a read-heavy scenario, like a marketplace.

4. Tools are not there, yet

Most developers don’t want to interact directly with the database and spend hours managing data, and that’s why ORM exist in the first place: Doctrine, Eloquent, Sequelize, Diesel, GORM, among what I can remember.

As you guessed, these libraries have deep roots on SQL, so SurrealDB won’t come quick enough for these unless a driver is developed for that translates the ORM queries and conventions to SurrealDB. These kind of drivers or adapters are still far away.

SurrealDB is interesting, but still miles ahead

SurrealDB is not the present, not by a long shot, but it may be the future for projects that want to start now with a flexible database. For this to become the “next thing”, there are three things that must happen:

• Tools for common frameworks
• Migration paths from old SQL databases
• Same or better performance than standard SQL engines.

Tools are coming, that’s for sure, and once these tools are live for most systems, migrations paths will be next. Performance will probably be the last part, but the most important to tackle soon, because benchmarks will appear and first impressions will be key.

If everything doesn’t happen as it should, then SurrealDB will stay as prototyping tool, a backend for hobby projects, or the shadow of proven solutions. Those are the first steps for SurrealDB be considered as a contender, which as of today, is still not.