Why Conversations Don't Belong in Relational Databases

When building chatbot platforms or conversational agents, developers often try to store conversation logic in relational or document-based databases. But here’s the problem:

Conversations aren’t tables. They’re networks.

This article explores why traditional databases struggle with conversation modeling and why Wanderer takes a different path using graphs.

Tables Are for Structured Data. Conversations Aren’t.

Relational databases are great when your data fits into predictable rows and columns think products, invoices, users. This is the basis for CRUD apps (Create, Read, Update, Delete) and admin panels.

But conversations aren't structured like spreadsheets. They're full of:

• Conditional paths
• Branching questions
• Loops and returns
• Deep context dependencies

Trying to force this into a tabular model means you're constantly writing glue code to simulate logic that just doesn’t belong there.

Let’s Try It Anyway…

Imagine trying to store a conversation like this:

1. A user is greeted with a question.
2. Depending on their answer, the bot either asks a follow-up, jumps to another branch, or ends.
3. Some answers lead to the same node. Others diverge. Some depend on earlier context.

In a relational model, you'd need:

• A questions table
• A suggestions (answers) table
• An edges table connecting questions and answers with conditions

Here’s a simplified version:

questions:

suggestions:

edges:

It works but only in theory. As your flows grow, the model becomes unmanageable.

• You’d need recursive queries or stored procedures to resolve the next valid step.
• You’d constantly join and filter across multiple tables.
• Traversing the logic visually or debugging it becomes nearly impossible.

Document Stores Aren’t Much Better

MongoDB and other document databases offer more flexibility. But you still face the same challenge: relationships.

You can either:

• Nest everything (but then reuse becomes difficult), or
• Reference everything (but then querying and joining gets ugly again)

In short: neither tabular nor document structures naturally express networks.

Conversations Are Graphs

At Wanderer, we treat every flow as a graph:

• Nodes represent questions, messages, actions, etc.
• Edges represent the logic between them - may, must, not, push, call.
• States flow through the system, triggering changes based on edge logic.

This allows us to:

• Model even the most complex conversational structures
• Visualize flows clearly, with every logical condition visible
• Traverse the graph deterministically or reactively
• Store and share flows as clean, portable JSON

In a graph, your data is your logic. And your logic is visual.

From Theory to Practice

With Wanderer, the conversation graph is the database. The flow you draw is what gets saved. There’s no translation layer, no hidden logic, and no mismatch between front-end and back-end.

And best of all: it runs entirely in the browser.

Final Thoughts

Relational and document databases were never designed for conversational logic. The more you try to force it, the more complexity you create. Wanderer embraces the true structure of conversations as networks and makes them visible, editable, and executable.

If you’re tired of fighting against your database schema, try building with the graph instead.

Start the Builder

Title image: https://pixabay.com/de/photos/karten-katalog-schubladen-holz-194280/