Why You Should Be Using SurrealDB

Intro

The database landscape has been dominated by relational databases for over forty years. PostgreSQL, MySQL, SQL Server — these are the workhorses of the internet. They’re battle-tested, well-understood, and reliable.

But they were designed in an era of monolithic applications, fixed schemas, and predictable data shapes. The world has changed. Applications are distributed. Data is increasingly connected, nested, and polymorphic. Real-time requirements are no longer optional. Developers spend too much time fighting object-relational impedance mismatch and managing migration scripts.

SurrealDB takes a fundamentally different approach. It’s not another incremental improvement on the relational model. It’s a rethinking of what a database should be for modern applications.

The Problem With Traditional RDBMS

Let me be clear: relational databases are not bad. They’re extraordinary pieces of engineering that power most of the world’s critical systems. If you’re building a traditional web application with well-defined, tabular data, PostgreSQL should probably be your default choice.

But they come with limitations that are increasingly difficult to ignore:

Schema rigidity. Changing a schema in a relational database means migration scripts, downtime planning, and coordination across teams. In a world of rapid iteration, this friction is expensive.

Object-relational impedance mismatch. Your application thinks in objects, nested structures, and relationships. Your database thinks in rows, columns, and joins. The translation layer — ORMs, mappers, serializers — is a constant source of bugs and performance issues.

Scaling challenges. Relational databases scale vertically by default. Horizontal scaling requires careful sharding strategies, read replicas, and complex infrastructure. It’s possible, but it’s not what they were designed for.

Graph relationships are unnatural. Real-world data is highly connected. A user has friends, who have posts, which have comments, which have authors, who have preferences. In SQL, this means complex joins across multiple tables. The more connected your data, the more painful the queries become.

They’re old. PostgreSQL was first released in 1996. MySQL in 1995. The fundamental architecture — tables, rows, columns, joins — was designed when a terabyte was an unimaginable amount of data and a “real-time” requirement meant seconds, not milliseconds.

Again: these databases are extraordinary at what they do. But what they do was defined by the constraints and assumptions of a different era.

What SurrealDB Brings

SurrealDB is a multi-model database. It combines document, graph, and relational capabilities in a single engine. You don’t choose a data model — you use the one that fits each part of your domain.

Multi-Model By Design

In SurrealDB, you store records — flexible documents that can embed nested data, define relationships through graph edges, and enforce structure through schemas when you want them. One database, one query language, multiple data models.

This means:

• Store a user profile as a document with nested preferences and settings
• Define a relationship between that user and their orders through a graph edge
• Query across all of it with a single, expressive query

No ORM. No joins across tables. No polyglot persistence with multiple databases each doing one thing.

SurrealQL

SurrealQL is SurrealDB’s query language. It’s designed to feel familiar to SQL users while being purpose-built for multi-model data.

SELECT *, ->purchased->product.* AS purchase_history
FROM user
WHERE age > 21
FETCH friends, friends.friends

This single query retrieves a user, their purchase history (through a graph traversal), and their friends — including friends of friends. The equivalent in SQL would involve multiple JOINs, subqueries, and application-level assembly.

SurrealQL supports SELECT, INSERT, UPDATE, DELETE — standard operations — but also graph traversal, subqueries, array operations, and geospatial functions. It’s not SQL. It’s better for the data shapes modern applications actually deal with.

Real-Time Capabilities

SurrealDB supports live queries: subscribe to a query and receive push notifications when the result set changes. This eliminates the need for polling, WebSocket infrastructure, and cache invalidation logic for real-time features.

Edge And Embedded

SurrealDB can run as a distributed cluster, a single server, or embedded directly in your application — the same binary, the same API. You can develop locally against an embedded instance and deploy to a distributed cluster without changing a line of code.

This is particularly powerful for edge computing and IoT applications where you need database capabilities close to the user or device.

Schema Flexibility

SurrealDB lets you choose. You can run schemaless — just insert documents and go. Or you can define strict schemas with field types, validation rules, and table-level access controls. You can even mix both: strict schemas for critical data, flexible documents for evolving features.

The Ecosystem: Tools Like AeroDB

A growing ecosystem is emerging around SurrealDB, including managed hosting platforms and developer tools. AeroDB, for instance, offers a managed SurrealDB service that handles deployment, scaling, backups, and monitoring — similar to what RDS and Cloud SQL do for PostgreSQL and MySQL, or what MongoDB Atlas does for MongoDB.

This ecosystem maturity is important. A database isn’t just the engine. It’s the tooling around it: hosting, monitoring, backup and recovery, client libraries, ORMs, and community support. SurrealDB’s ecosystem is younger than PostgreSQL’s — that’s the trade-off — but it’s growing rapidly, and tools like AeroDB are closing the gap.

When SurrealDB Is The Right Choice

SurrealDB excels when:

• Your data is graph-oriented. Social networks, recommendation engines, organizational hierarchies, supply chains — any domain where relationships between entities are first-class citizens.

• You need real-time updates. Dashboards, collaborative applications, live feeds — anywhere users expect to see data change without refreshing.

• You’re building a modern web or mobile application. SurrealDB’s document model maps naturally to JSON APIs. No translation layer. No ORM. Store what your frontend needs.

• You want to move fast. Schemaless by default means you can iterate on your data model without migration scripts. Add fields, change structures, experiment — the database adapts.

• You’re deploying to the edge. The embedded mode lets you run a full database alongside your application, minimizing latency and simplifying infrastructure.

When PostgreSQL Is Still The Right Choice

SurrealDB is not a PostgreSQL replacement. It’s a different tool for different problems. Stick with PostgreSQL when:

• Your data is fundamentally tabular. Financial transactions, inventory systems, timeseries data — data that naturally fits in rows and columns.

• You need mature ecosystem support. PostgreSQL has decades of tooling: ORMs, migration frameworks, monitoring tools, extensions (PostGIS, pgvector, TimescaleDB). If your stack depends on this ecosystem, SurrealDB isn’t there yet.

• You have strong ACID requirements across complex transactions. SurrealDB supports transactions, but PostgreSQL’s transaction model is more mature and battle-tested.

• Your team knows SQL deeply. SQL is one of the most widely understood languages in computing. SurrealQL is new. Training and hiring matter.

• You’re not hitting the limitations. If PostgreSQL is working well for your use case, don’t change databases because a blog post told you to. The best database is the one that solves your problems.

Getting Started

1. Install it locally. SurrealDB has a single binary. Download it, run surreal start, and you have a working database.

2. Try Surrealist. The official GUI lets you explore data, write queries, and visualize graph relationships. It’s the best way to understand the multi-model capabilities.

3. Start with a side project. Don’t rewrite your production system. Build something new where SurrealDB’s strengths align with your requirements.

4. Join the community. The SurrealDB Discord and GitHub are active and helpful. The documentation is comprehensive and improving rapidly.

5. Consider managed hosting. If you’re deploying to production, evaluate managed options like AeroDB to handle the operational overhead.

How Microbians Can Help

At Microbians, we help businesses choose and implement the right database for their specific needs. Sometimes that’s PostgreSQL. Sometimes it’s SurrealDB. Sometimes it’s a hybrid approach with specialized databases for specialized workloads.

We’ve worked with multi-model databases in production environments and understand both the opportunities and the challenges. If you’re evaluating SurrealDB for your next project, we can help you make an informed decision and implement it correctly.

Conclusion

Databases shouldn’t be chosen out of habit. The relational model has served us well for decades, and it will continue to serve many use cases for decades to come. But modern applications have requirements that the relational model was never designed to handle.

SurrealDB represents a genuine evolution in database design. Its multi-model approach — documents, graphs, and relations in a single engine — maps more naturally to how applications actually work. Its real-time capabilities, schema flexibility, and embedded deployment model address real pain points that SQL databases struggle with.

Is it right for every project? No. Is it worth understanding and evaluating for your next one? Absolutely.