Not sure what SurrealDB is and what the hype is about? Read my introduction here.
Last week the SurrealDB team announced version 2.0, with major changes encompassing internal changes such as a new parser and a caching layer, as well as exposing new syntax and an experimental GraphQL API. For a full review written by the team you can read their awesome post here.
This version has many amazing features, and instead of running down the list of features like they did, I would like to discuss how the features show how the project is becoming more mature and why I think this marks the beginning of the tool becoming more generally accepted.
I will categorize the features into two groups:
- Changing Surreal to use more industry standards
- Addressing the community’s major pain points of performance and snapshots
Welcoming existing standards
For a long time, SurrealDB was the king of inventing new concepts. This was not like any other database anyone has ever seen. This had both positive and negative implications. On one hand — people were excited to be able to model more complex data in a simpler way with powerful querying syntax. On the other hand, however, the learning curve for Surreal was quite steep. You had to learn both the data model and the query language before being able to work properly with the DB, which put off many.
In this release, Surreal’s direction moves more into industry standards that all of us working with data have come to both accept and love. In my opinion, the feature that shows this most clearly is the GraphQL API, but it also shines through many of the smaller features as well.
GraphQL
Since it’s invention, GraphQL has quickly become one of the world’s favorite API standards, one of the main reasons being the fact that it moves the power into the hands of the data consumers (be it the frontend site or different services) by enabling each consumer to request exactly the data it needs.
This reason is also why this is such a good fit for SurrealDB — which aims to be an all-in-one backend solution. By welcoming GraphQL with open arms, Surreal leaps forward in several key aspects:
- The learning curve dramatically decreases: GraphQL’s language is more generally known and is less complex than SurrealQL’s more niche features.
- SurrealDB can now be a drop-in replacement! I can’t understate the importance of this. The hardest part of using a new technology is that fact that our application usually have existing code to request data. For many, this is GraphQL, which means adopting SurrealDB into new projects has never been easier!
Other Features
Many other features also nod to the fact that Surreal is accepting the standard terminology, making it easier for experienced data practitioners to use the project. I’ll quickly go through them:
- Define access moves to a more accepted access terms instead of Surreal’s tokens. The new access statement also accepts known methods such as JWT.
- Nested field definition as literals. Experience teaches us that the more strict the data validation, the less bugs we’ll have. Enabling people to define complex types while maintaining strong typing makes the usage much more similar to any type-safe language or DB.
- Making UPSERT explicit. While in previous version UPDATE could also insert new data, in this version the UPDATE statement acts like it does in any other database and in order to create or update we need to explicitly declare we wish to do it. This will reduce bugs for people who come from other database solutions by a significant margin.
All of these features show a direction, in my opinion, that will make SurrealDB a more widespread and accepted solution.
User pain points
The second important aspect of this version is that it solves many of the major pain points users had head on.
Performance
One of the most common complaints about Surreal is that it sacrificed speed for flexibility, with user complaining it is slower that classical DBs such as Postgres. While not publicly available yet (they are now working on making them stable), many features in this release aim to make SurrealDB faster and more reliable. Let’s look at some of them:
- New parser: I’ve previously covered the way SurrealQL has been parsed in the previous version. The parsing has been rebuilt from the ground up to be more efficient and more flexible. I’ll write a more in-depth post on the subject in the near future.
- A new caching layer for faster queries without multiple round-trips to the underlying storage.
- Better Indices, that now have better algorithms, build asynchronously and can be rebuilt, all of which allows for faster queries on more data.
Snapshots
Ever accidentally deleted important data? Updated a field you shouldn’t have? Many databases have a concept of versioning, which allows querying previous iterations of the data. SurrealDB now joins the club by introducing their own storage solution — SurrealKV.
SurralKV is a replacement for the previous storage layers (RocksDB, TiKV, etc.) and allows for snapshot queries, which means you can see how the data looked on a specific time.
Conclusion
I see this version as a first huge step in a good direction.
This version showed how Surreal can balance both it’s own identity and the world’s best practices. I believe in the coming months and years we’ll see the product mature and become a product we can all look forward to using.
Interested in more SurrealDB deep dives? See all my posts here.
Please like and follow for more, I’ll be continuing my deep dives into the new features in version 2.0.
