SurrealDB: One Database to Rule Relational, Document, Graph, and Time-Series Data

You've probably seen the tweet: "One database that's relational, document, graph, and time-series at once." Sounds like marketing fluff, right? But then you look at the GitHub repo and realize it's actually real. Meet SurrealDB.

SurrealDB is an open-source, multi-model database that combines the best parts of relational, document, graph, and time-series databases into a single engine. No more stitching together PostgreSQL for structured data, MongoDB for flexibility, Neo4j for relationships, and InfluxDB for time-series. One database, one query language, one deployment.

What It Does

SurrealDB is a database that treats all data as first-class citizens. You can store JSON documents, run SQL-like queries, traverse graph relationships with ->friends->posts, and automatically append timestamps to data for time-series analysis — all in the same database. It uses a custom query language called SurrealQL (pronounced "surreal QL") that feels familiar if you've ever used SQL, but extends it with document, graph, and time-series operators.

Under the hood, it's built in Rust, so performance is solid, and it supports both embedded (libSQL-style) and client-server modes. It also handles real-time subscriptions, so you can get live updates on queries without polling.

Why It's Cool

Here's what makes SurrealDB unique:

Multi-model by default. You're not forced to pick one data model upfront. Define a table like a relational schema, then store arbitrary JSON in a field for flexibility. Add edges between records for graph traversal, and query them with SELECT * FROM person WHERE ->owns->car.brand = 'Tesla'. No joins on foreign keys — just graph-style path expressions.

Time-series built-in. Every record can be automatically timestamped, and you can query "time bucketed" aggregations with SELECT count(), avg(temp) FROM sensor WHERE time > d'2024-01-01' GROUP BY time(1h). No separate pipeline or special table needed.

Real-time subscriptions. Push data to clients without WebSocket gymnastics. LIVE SELECT * FROM person gives you a stream of insert/update/delete events to your app. Great for dashboards, collaborative tools, or live feeds.

Single-node and distributed. Start with a single binary for development, scale to a cluster for production. The API is the same.

ACID transactions. Yes, even with documents and graphs. No eventual consistency surprises.

Use cases? Anywhere you'd want a flexible schema with strong consistency: SaaS backends, IoT apps with time-series sensors, social graphs, inventory systems, or even as a drop-in for prototyping where you don't know your schema upfront.

How to Try It

Getting started takes 30 seconds.

Option A: Install locally

# macOS / Linux
curl -sSf https://install.surrealdb.com | sh

# Or run the prebuilt binary
surreal start --log trace --user root --pass root

Option B: Docker

docker run --rm -p 8000:8000 surrealdb/surrealdb:latest start

Option C: Cloud (if you're lazy) Sign up at surrealdb.com for a hosted instance.

Once it's running, open http://localhost:8000 in your browser (the built-in GUI) or connect with the surreal CLI:

surreal sql --endpoint http://localhost:8000 --ns test --db test --user root --pass root

Try this:

-- Create a relational table with document fields
DEFINE TABLE person SCHEMAFULL;
DEFINE FIELD name ON person TYPE string;
DEFINE FIELD metadata ON person FLEXIBLE; -- mixed JSON

-- Insert
INSERT INTO person (name, metadata, age) VALUES ('Alice', {avatar: 'alice.png', bio: 'DevOps engineer'}, 28);

-- Graph relationship
CREATE owns FROM person:alice TO car:tesla3;

-- Time-series query
INSERT INTO sensor (temp, room) VALUES (22.5, 'kitchen');
SELECT avg(temp), time(5m) FROM sensor GROUP BY time(5m);

The learning curve is shallow — if you know SQL, you're 80% there.

Final Thoughts

SurrealDB feels like the answer to a question developers have been asking for years: "Can I just use one database for everything?" It's not perfect — the ecosystem is young, the query language is still evolving, and documentation can be sparse for edge cases. But the core idea is solid, and the Rust foundation gives it real legs.

For side projects, MVPs, or even production systems where you want to avoid polyglot persistence, it's worth a serious look. Worst case, you learn a new query language and have fun. Best case, you simplify your stack by 75%.

Try it, break it, and file an issue. That's how good open source gets better.

Follow @githubprojects on X (Twitter) for more developer tools and open source discoveries.