DEV Community: Jakub Málek

I built an AI Second Brain on SurrealDB - and connected it to Claude via MCP

Jakub Málek — Tue, 24 Mar 2026 13:35:52 +0000

In my previous posts, I talked about why SurrealDB feels like the Swiss army knife of databases - graph relations, vector search, schemaful tables, and record links all in one engine. I wanted to put that to the real test, so I built a personal AI-powered knowledge system: a "second brain" that remembers everything I tell it, connects ideas automatically, and lets me search with natural language. But the part that really changed my workflow was exposing it as an MCP (Model Context Protocol) server - giving AI assistants like Claude Code direct access to my entire knowledge graph.

The core works like this: send a thought (text or voice via Telegram), and the system extracts entities, generates tags, creates embeddings, and detects duplicates using OpenAI. SurrealDB stores it all as a graph - thoughts linked to entities via mentions edges, similar thoughts connected through related_to edges with similarity scores. Search runs hybrid vector + fulltext in parallel. But the MCP layer is where it gets interesting. Claude Code can search my brain semantically, add new memories, update existing ones, archive outdated thoughts, and explore connections - all without me leaving the terminal. When I'm coding and need to recall a decision I made weeks ago, my AI assistant just knows. It's like giving your AI tools persistent, structured long-term memory.

What surprised me most was how naturally SurrealDB handles this multi-model use case. I didn't need a separate vector database, graph database, and relational store - it's all one system. HNSW vector indexes, RELATE statements, record links, and fulltext search coexist seamlessly. If you've been looking for a practical MCP server example or a reason to try SurrealDB beyond toy projects, the whole thing is open-source and ready to self-host.

GitHub: github.com/malekjakub69/mcp-second-brain

SurrealDB is Not a Silver Bullet: 3 Scenarios Where You Still Need a Backend

Jakub Málek — Wed, 18 Mar 2026 15:13:37 +0000

The "No-Backend" Hangover
Look, I know what I said. In my previous posts, I praised SurrealDB like it was the end of the "traditional" backend era. And for 80% of projects, it might be.

But as a medior dev who’s seen his fair share of architectural disasters, I have to be honest: SurrealDB is not magic. If you try to build everything directly on top of the database, you’re eventually going to hit a wall. Sometimes, you just need a "boring" server running Node, Rust, or Go. Here are three reasons why I’m not deleting my Express/Hono repositories just yet.

1. The "Secret Key" Problem (Integrations)
SurrealDB can handle authentication, but it shouldn't be your "Integration Hub."

If your app needs to talk to Stripe, SendGrid, or a 3rd party AI API, you have a problem. You cannot—and I repeat, CAN NOT—expose your secret API keys to the frontend, even with the best Row-Level Security in the world.

The Reality Check: Anything that requires a sensitive handshake with another service belongs in a secure, server-side environment.

2. Heavy Lifting & CPU-Intensive Tasks
SurrealQL is powerful, but it’s a query language, not a general-purpose programming language.

Scenario: You need to resize an image, generate a complex PDF invoice, or run a local AI model inference to score a user's trust level.

The Reality Check: Doing this inside a database layer (even with future-ready functions) is like trying to win a Formula 1 race in a very fast tractor. It's the wrong tool. You need a dedicated microservice that can scale horizontally to handle the CPU load.

3. Proprietary "Black Box" Logic
Sometimes, your business logic is your "secret sauce." If your sorting algorithm or your AI-matching logic is what makes your startup unique, you might not want it sitting in a database schema where (even if secured) it's closer to the edge than you'd like.

The Reality Check: Complex state machines or proprietary algorithms are often easier to write, test, and debug in a standard backend environment with full-fledged logging and monitoring tools.

My "Hybrid" Advice
I don't choose between "No-Backend" and "All-the-Backend." I use a hybrid approach:

SurrealDB handles the data, the simple CRUD, and the real-time sync.
A Slim Backend (Edge Functions) handles the "heavy" stuff: payments, sensitive integrations, and complex AI processi ng.

Conclusion
Don't be a zealot. SurrealDB is a massive leap forward for developer productivity, but don't let the "No-Backend" dream turn into a "High-Maintenance" nightmare. Use the right tool for the job.

What’s your take? Have you tried building a "pure" DB-only app, or did you crawl back to Node.js after a week? Let's discuss in the comments!

SurrealDB: Why JOINs are So 2010 and How Graphs Change Everything (Part 3)

Jakub Málek — Tue, 17 Mar 2026 00:49:32 +0000

The Mental Gymnastics of Data
We’ve all been there. You start with a simple Document DB because "it’s flexible." Then your boss says: "Hey, can we show which friends of this user liked the same products in the last 24 hours?"

Suddenly, your "flexible" NoSQL setup becomes a nightmare of application-side joins, or you’re staring at a SQL query so long it looks like a spell from Harry Potter.

As a medior dev, I’ve learned that the hardest part of coding isn't the logic—it's managing the relationships between data without losing your mind. That’s where the "Surreal" in SurrealDB finally clicks.

Graphs vs. Joins: The Arrow Power 🏹
In traditional SQL, you have "Join Tables" (the middleman nobody likes). In SurrealDB, records can point to each other directly using Graph relations.

Instead of a 20-line JOIN statement, you use arrows. It’s intuitive, it’s fast, and it’s actually readable:

-- Find all products liked by people I follow
SELECT ->follows->person->liked->product FROM user:tobias;

Read that again. It’s like writing a sentence. follows and liked aren't just strings; they are edges that can hold their own data (like when you followed them).

The Multi-Model Secret: You Don't Have to Choose
The biggest "Lazy Dev" win? You don't need a separate Graph DB (like Neo4j) and a Document DB (like MongoDB).

Want to store a messy JSON? Go for it.
Want to enforce a strict schema? One command away.
Want to link them with graph edges? It’s already built-in.

It’s the "Swiss Army Knife" of databases. For someone like me who balances Frontend, AI, and startup chaos, not having to manage three different database clusters is a lifesaver.

AI and Connected Data
Since I’m building a watchdog for AI trust levels, I need to see how data points connect. AI thrives on context. SurrealDB’s ability to traverse relationships instantly makes it the perfect backbone for AI-driven apps where context is everything.

The Series Wrap-Up: Is SurrealDB for You?
We’ve covered the "What," the "Backend-less" magic, and the "Graph" power.

My verdict? If you’re building a massive legacy banking system, stick to your COBOL and PostgreSQL. But if you’re a freelancer, a startup founder, or just a developer who values their time and sanity—give SurrealDB a spin.

It’s not just a database; it’s a way to make development fun again.

SurrealDB: How I Deleted 70% of My Backend Code (Part 2)

Jakub Málek — Mon, 16 Mar 2026 16:33:59 +0000

Remember that "simple" Express server?
We’ve all been there. You just want a user to be able to update their own profile. So you:

Write an /api/update-profile endpoint.
Validate the JWT (and pray the library doesn't have a new CVE).
Fetch the data from the DB.
Manually check if the user_id from the token matches the owner_id in the DB (because you don't want me changing your profile picture).
Save it and send a 200 OK.

Congratulations, you just wrote 50 lines of boilerplate that we’ve been writing since 2015. It’s 2026-we should be over this. As a freelancer and working with AI, I’ve realized one thing: The best code is the code I don’t have to maintain.

Enter SurrealDB and its "Backend Killer" mode.

The Secret Sauce: Row-Level Security (RLS)
SurrealDB isn't just a bucket for your data; it’s an intelligent layer. Instead of writing logic in Node.js or Python, you define permissions directly in the database schema. It looks like this:

-- Define the 'post' table
DEFINE TABLE post SCHEMAFULL
  PERMISSIONS
    -- Anyone can see public posts
    FOR select WHERE public = true
    -- Only the author can edit or delete their own posts
    FOR update, delete WHERE author = $auth.id;

See that $auth.id? That’s the magic. The database already knows who is logged in. You don't need a custom middleware to check ownership for every single request.

Connecting from the Frontend? (Don't Panic!)
This is the part where senior architects usually have a mini-heart attack: "You want to connect to the DB directly from the browser?! That’s a security nightmare!"

Actually, it’s not. With SurrealDB Scopes, you define exactly how users authenticate (Email/Password, OAuth, etc.). Once they’re in, the database enforces the PERMISSIONS globally.

The "Lazy Developer" result:

Zero CRUD API code: No more writing boring REST or GraphQL wrappers.
No ORM headaches: No more mapping objects to tables.
Frontend Power: Your React/Svelte app just calls db.update('post:1', data) and the DB handles the rest.

Why this matters for the AI-heavy stack
I spend a lot of time merging design with functional AI tools. I'm currently building a tool that monitors how much we actually trust AI (ironic, since I probably trust it too much myself).

When you're building AI-driven apps, complexity is your enemy. By offloading the "plumbing" (auth and permissions) to SurrealDB, I have more brainpower left to focus on the AI logic and the UI. It’s about being efficiently lazy.

What’s next?
In the final part of this series, we’ll look at the "Surreal" part of SurrealDB: Mixing Graphs and Documents. I’ll show you how to run a "friends-of-friends" query without your brain melting from SQL JOINs.

Stay tuned, and go delete some unnecessary backend code today!

SurrealDB: The "One-Size-Fits-All" Database for Lazy Developers (Part 1)

Jakub Málek — Sun, 15 Mar 2026 06:13:40 +0000

*Intro: * We need to talk about your "Modern Stack"
Let’s be real for a second. We’ve all been there: You have a "simple" project idea. Two hours later, you’re staring at a Docker Compose file with PostgreSQL, Redis for caching, Neo4j because "graphs are cool," and a Node.js backend just to move JSON from A to B.

Why are we doing this to ourselves?

I’m a medior dev. I’ve reached the point in my career where I’m too tired to write the same CRUD boilerplate for the 100th time. I just want to build things that work. And that’s when I stumbled upon SurrealDB.

What is SurrealDB? (Besides a cool name)
Imagine if SQL, MongoDB, and GraphQL had a baby, and then that baby was raised by Firebase but grew up to be actually flexible.

SurrealDB is a multi-model database. It doesn't care if you want documents, relational tables, or complex graph structures. It just says: "Sure, why not both?"

Why you (as a lazy dev) should care:
The "Backend Killer" (No, seriously): SurrealDB has built-in Row-Level Security (RLS) and authentication. You can connect your frontend (React, Vue, whatever) directly to the database. No more writing 500 lines of Express.js just to check if user_id === owner_id.

Schema-Flexible (The "I'll decide later" feature):
You can start schema-less (just dump data) and then enforce a schema once you actually know what you're building. It's perfect for prototyping without the "oops, I forgot a migration" headache.

*Graph Relations without the PhD: *
Remember trying to write a recursive CTE in SQL to find "friends of friends"? In SurrealDB, it's literally just an arrow: SELECT ->knows->person FROM user:me. My brain thanked me.

A Quick Reality Check
Is it magic? Almost. Is it perfect? Well, it's still evolving. But if you're building a startup or a side project and you're a "team of one," using a traditional stack is like bringing a tank to a knife fight. It’s overkill and you’ll probably hurt yourself.

What’s next?
In the next part of this mini-series, I’m going to show you how I deleted 70% of my backend code using SurrealDB’s auth layer.

Spoiler: It felt amazing.