When Feelings Need a Graph How SurrealDB Became the Heart of Our Mental Wellness #SurrealDB #MongoDB #MentalHealthAI #MultiModal

BAPANAPALLI PRANEETA — Mon, 27 Apr 2026 09:56:59 +0000

Authors:

@bapanapalli_harshita_a332 -Bapanapalli Harshita
@vkaparna_07 -V K Aparna
@bapanapalli_praneeta -Bapanapalli Praneeta
@sreepurnima07 -Saripalli Venkata Sree Purnima

Mental wellness apps keep solving the wrong problem. They get better at delivering content — more exercises, nicer animations, smarter copy — without ever fixing the thing that makes them feel hollow: they don't remember you.

You can tell an app that work deadlines spike your anxiety, that a certain breathing exercise helped last Tuesday, that you've had a rough week. Next session, none of that exists. The chatbot starts fresh. Whatever you shared is gone.

That's not a UX problem. It's a data architecture problem. And you can't patch it with a better model or a warmer tone. You need a persistence layer that actually reflects how emotional data is shaped — not as flat logs, but as a web of relationships between states, triggers, and what helped. That's what this post is about.

SurrealDB is the emotional memory layer. MongoDB is the operational backbone. Together they handle what neither could do well alone — and that split is what makes real personalisation possible.

01 — The Problem Every Wellness App Gets Wrong

We didn't start with a technical problem. We started with a frustration. Talk to most mental health apps and you get the distinct sense the system doesn't know you — because it doesn't. Every session is a clean slate.

The problem goes deeper than memory, though. Text-only systems miss the gap between what someone types and what they're actually feeling. Type "I'm fine" while your face quietly shows 75% sadness, and the app nods along. It has no idea it just gave the wrong response. And even the apps that do accept camera or voice input rarely connect those signals meaningfully over time — they still pull from the same static list of exercises.

No session continuity. Every conversation is a first meeting. No accumulated context, no pattern recognition across sessions — just a reset chatbot each time you open the app.
Single-channel input misses the contradiction. A person can type one thing and feel another. Until you're reading face, voice, and text together, you're only getting part of the signal — and sometimes the least honest part.
Static recommendation lists aren't personalisation. Five coping exercises served identically to every user regardless of history. That's a vending machine, not a support system.
Memory without structure is just logs. Chat history sitting in a database isn't memory. You need to know why someone felt a certain way, what preceded it, and what actually helped. That requires relationships between data points — which means a graph.
The access gap is real. Professional mental health support is expensive, stigmatised, and heavily waitlisted. The digital tools meant to fill that gap keep hitting the same ceiling.

When a user types "I'm fine" but the camera detects sadness at 0.75 confidence, a text-only system gives entirely the wrong response. Fusing all three channels and storing the history of those fused signals is what actually closes the empathy gap.

02 — Why Two Databases? Why These Two?

Once we started designing in earnest, we realised the data had two very different shapes — and fighting that shape is how you end up with a mess.

Mood logs, conversation history, journal entries, game streaks — all of that grows linearly. Clear timestamps, queried by user and date, aggregates cleanly into weekly summaries. Standard document-store territory.

But emotional relationships don't look like that. "This user feels anxious when a work deadline is near. This breathing exercise has helped three times in that situation." That's not a document. That's a graph. You can't scan it — you need to traverse it. Trying to cram those relationships into MongoDB collections is how you end up with nested lookups, stitched-together queries, and a codebase that gets messier with every new relationship type you add.

So we drew a clean line. MongoDB for the backbone. SurrealDB for the memory.

MongoDB is right for:	SurrealDB is right for:
Flat records with clear schemas	Relationship traversal across emotional nodes
Date-range queries & aggregation	"What worked for this person in this context?"
Linearly growing log-style data	Patterns that grow richer as connections accumulate
Dashboard analytics & trend charts	Context-aware, personalised recommendations
Indexed lookups < 50ms	Single-hop graph queries < 100ms
User profiles, journals, streaks	Emotion–Trigger–Solution memory graph

03 — SurrealDB — Where Emotional Memory Lives

This is the part that makes the chatbot feel like it actually knows you — not because it's scripted to sound warm, but because it's reading from a real, growing graph of your emotional history.

Every interaction builds out the same four-node structure:

User → Emotion → Trigger → Solution

Each session either creates a new node or strengthens an existing connection. After a few weeks the graph knows which triggers are common for this specific person, which interventions actually land, and which ones get skipped.

Single-hop queries only — deliberately. No recursive traversals. This keeps every graph query under 100ms. Any perceptible lag in a therapeutic conversation breaks the experience. We traded theoretical graph depth for guaranteed speed.
The graph is the personalisation engine. A new user and a returning user get fundamentally different responses — not because of manual rules, but because the graph naturally represents their different histories.

Runtime Table Initialization

const DEFAULT_TABLES = [
  "MoodEntry",
  "CameraMoodAnalysis",
  "MoodPrediction",
  "ChatConversation",
  "JournalEntry",
  "CrisisAlert",
  "WeeklyReport",
  "JournalAnalysis",
  "Quote",
  "Achievement",
  "UserWellness",
  "User"
];

async ensureTable(table) {
  const safe = sanitizeTableName(table);
  await this.client.query("DEFINE TABLE " + safe + " SCHEMALESS;");
}

// during init:
for (const table of DEFAULT_TABLES) {
  await this.ensureTable(table);
}

SCHEMALESS means SurrealDB won't reject documents with unexpected fields — useful during development when the emotional graph is still evolving. sanitizeTableName prevents injection via dynamic table strings.

Metrics Write & Aggregation

def write_metric(self, user_id, metric_type, value):
    query = "CREATE metrics CONTENT {user_id: $user_id, metric_type: $metric_type, value: $value, created_at: time::now()};"
    return self._rpc("query", [query, {"user_id": user_id, "metric_type": metric_type, "value": value}])

def dashboard_stats(self, user_id="anonymous"):
    query = (
        "SELECT metric_type, count() AS points, math::mean(value) AS avg_value "
        "FROM metrics WHERE user_id = $user_id GROUP BY metric_type;"
    )
    rows = self._rpc("query", [query, {"user_id": user_id}])

write_metric appends a timestamped record to the metrics table — mood scores, activity completions, streak counts. dashboard_stats aggregates them in a single SurrealDB query using the built-in math::mean and count() functions, so the Python layer never needs to do the arithmetic itself.

In MongoDB you'd be joining multiple collections or nesting queries in application code — and that complexity compounds with every new relationship type. Graph queries handle it in one hop.

04 — MongoDB — The Quiet Backbone

If SurrealDB is the memory, MongoDB is the spine. It holds the everyday data in a shape that's easy to query, aggregate, and extend when we add a new feature.

The most important design choice here was tagging every mood log at write time. When a session ends, we record the raw sentiment scores from all three channels alongside the fused score and the emotional tags. We don't recalculate later. The record is a snapshot of what was detected in the moment — which matters when you're building trend lines or comparing weeks.

MongoDB — Mood Log Document

def add_mood_log(self, user_id, payload):
    doc = {"user_id": user_id, "payload": payload, "created_at": datetime.now(timezone.utc)}
    self.db.mood_logs.insert_one(doc)

Every mood log is written with a UTC timestamp at insert time. The payload carries the raw sentiment scores from all three channels alongside the fused score and emotional tags. When we query for trend data, the snapshot is already there — no recalculation needed.

MongoDB — Compound Index

Adding a compound index on user_email and updated_at delivered a significant speedup on conversation queries once data started to scale. Cheap to add early, expensive to retrofit.

// Index for efficient querying
chatConversationSchema.index({ user_email: 1, updated_at: -1 });

MongoDB — Journal Entry with Sentiment Summary

Each journal entry is processed sentence by sentence. The AI service builds a structured summary object that attaches to the entry at write time — so the sentiment label and score are pre-computed and ready for the dashboard without a second pass.

return {
  summary_title:
    topEmotion === 'happy'  ? 'Positive Pattern' :
    topEmotion === 'sad'    ? 'Low Mood Pattern'  :
    topEmotion === 'stress' ? 'Stress Pattern'    : 'Anxiety Pattern',
  analysis: `${baseSummary}${themeText} The dominant emotion appears to be ${topEmotion}.`,
  emotion: topEmotion,
  sentiment: sentiment.sentiment,
  sentiment_score: Number((sentiment.score * 2 - 1).toFixed(2)),
  summary: `${topEmotion.charAt(0).toUpperCase() + topEmotion.slice(1)} was the strongest emotional signal in this entry.`,
  ...
};

05 — Reading Emotion Across Three Channels

The architecture only matters if the emotion data flowing into it is accurate. We capture three separate signals, process them independently, and merge into one weighted score before anything gets stored.

Text — Sentiment.js

An affective lexicon with a four-word context window. "Not happy" flips polarity. "Very" and "extremely" amplify magnitude. Output is a continuous float from −1 to +1 — not a category label, which matters for the fusion step.

import Sentiment from 'sentiment';
const sentimentAnalyzer = new Sentiment();

export function advancedSentimentAnalysis(text) {
  ...
  const sentimentResult = sentimentAnalyzer.analyze(text);
  ...
  return {
    sentiment: primarySentiment,
    score: Math.round(normalizedScore * 100) / 100,
    confidence: Math.round(confidence * 100) / 100,
    emotion_states: topEmotions,
    subEmotions: detectedEmotions.slice(0, 5),
    raw_score: sentimentResult.score,
  };
}

Voice — Web Speech API

Browser-native transcription, zero server overhead. The transcript goes through the exact same advancedSentimentAnalysis pipeline. Honest limitation: no confidence signal from the API, so transcription errors score silently. We chose it for reach — any modern browser, no install required.

Facial Expression — face-api.js

TinyFaceDetector locates the face. FaceExpressionNet classifies across seven emotion categories. Everything runs client-side — no camera frames leave the browser.

const detections = await faceapi
  .detectAllFaces(image, new faceapi.TinyFaceDetectorOptions({ inputSize: 416, scoreThreshold: 0.45 }))
  .withFaceExpressions();

const expressions = bestDetection.expressions || {};
const ranked = Object.entries(expressions).sort((a, b) => b[1] - a[1]);
const [expression = 'neutral', confidence = 0.5] = ranked[0] || ['neutral', 0.5];

Fusion — One Score from Three Channels

This fuses week description text + mood notes + journal content into one wellness score. Text and mood signals are weighted and clamped, then combined — mood history carrying more weight when available.

function computeWeeklySignals({ weekDescription = '', moods = [], journals = [] } = {}) {
  const textParts = [
    String(weekDescription || ''),
    moods.map((m) => `${m.mood || ''} ${m.note || ''}`).join(' '),
    journals.map((j) => j.content || '').join(' '),
  ];
  ...
  const scoreFromText = 6 + Math.max(-2, Math.min(2, (positiveWordHits - negativeWordHits) / 4));
  const scoreFromMoods = 6 + Math.max(-2.5, Math.min(2.5, moodAverage * 1.4));
  const combinedScore = moods.length > 0
    ? (scoreFromText * 0.35) + (scoreFromMoods * 0.65)
    : scoreFromText;
  const wellnessScore = Math.max(1, Math.min(10, Math.round(combinedScore)));
  return { wellnessScore, ... };
}

Face gets the highest weight because it's the hardest signal to fake. Typing "I'm fine" takes half a second. Consistently suppressing a micro-expression of sadness is physiologically much harder. When face detection fails, weights redistribute automatically — the score degrades gracefully rather than erroring out.

Models used: Sentiment.js for text scoring. TinyFaceDetector + FaceExpressionNet from face-api.js for client-side expression classification. Web Speech API for voice transcription. Gemini API as fallback for ambiguous fused signals. The mood predictor is a custom weighted formula — no GPU, no retraining.

06 — Catching the Dip Before the User Notices It

Most apps wait for a user to say something is wrong. We wanted to catch the slide before it fully landed — ideally before they'd put words to it themselves.

Mood Predictor

The predictor combines mood history with real-time contextual inputs — current feeling, sleep hours, stress level, energy level, and activity data — into a single weighted forecast.

const forecast = predictMoodWeighted({
  moodHistory: recentMoods,
  currentFeeling,
  sleepHours,
  stressLevel,
  energyLevel,
  activityData: source.activityData || {},
});

No trained model, no GPU, no retraining cycles. Just a weighted formula on each user's own history combined with today's self-reported context. Recent entries carry more weight; older ones fade — and the contextual signals let the predictor react to a bad night's sleep before the mood drop shows up in the log.

"Catching someone's bad day before it arrives isn't just a technical achievement — it's the whole point of building this in the first place."

07 — The Full System Architecture

Every component has a clear job. React captures input. Express handles fusion. MongoDB stores document-shaped data. SurrealDB holds the emotional graph. Django and Graphene sit in the middle as a unified GraphQL bridge, so React only ever talks to one endpoint.

Layer	Technology	Role
Frontend	React	Text, voice (Web Speech API), camera (face-api.js)
Backend	Express.js	Fusion logic, aiInsights endpoints, API routing
Doc store	MongoDB Atlas	Chat history, mood logs, journals, game streaks
Graph store	SurrealDB	Emotion–Trigger–Solution graph, personalisation memory
API bridge	Django + Graphene (GraphQL)	Unified endpoint connecting both databases to React
Client	Apollo Client	GraphQL queries with in-memory caching
Prediction	Custom Node.js	Weighted average on mood history + contextual signals
LLM fallback	Gemini API	Handles low-confidence fused signals
Animations	Framer Motion	Breathing timer, gratitude challenge, emotion game
Dashboard	Recharts + d3-scale	Mood timeline, heatmap, trigger frequency charts

GraphQL Schema — Django + Graphene Bridge (`schema.py`)

class Query(graphene.ObjectType):
    invoke_llm   = GenericScalar(...)
    chat         = GenericScalar(...)
    mood_forecast = GenericScalar(...)
    ...

class Mutation(graphene.ObjectType):
    run_health_check = RunHealthCheck.Field()

GraphQL Endpoint Wiring

# urls.py
path("graphql/", csrf_exempt(GraphQLView.as_view(graphiql=True))),

# settings.py
GRAPHENE = {
    "SCHEMA": "core.schema.schema"
}

Apollo Client caches moodTrend and recommendations in memory — most data doesn't hit the network more than once per session. The Django + Graphene layer is why the React client never needs to know, or care, that two completely different databases are sitting underneath.

Performance Targets — and How We Hit Them

→ End-to-end under 700ms. From camera frame to personalised response — detection, fusion, graph lookup, recommendation — all in under three-quarters of a second.

→ SurrealDB single-hop queries under 100ms. Maintained by design through the shallow-query constraint.

→ MongoDB indexed lookups under 50ms. Once the compound index on user_email and updated_at is in place.

→ Heavy operations are edge paths. Face model inference and Gemini LLM calls only fire when needed. The happy path stays fast.

08 — What the User Actually Experiences

The architecture only earns its place if it produces something genuinely better for the person using it.

A Chatbot That Actually Remembers

Beta users described suggestions as feeling like they "actually fit my situation." That's harder to achieve than it sounds. The chatbot isn't using warmer language because it was trained to seem caring. It's making relevant recommendations because it genuinely knows your history. People can feel that difference — and it's the difference between a tool and a companion.

Mood Calendar and Emotional Heatmap

Daily mood scores displayed as a composed line chart with rolling variance as a soft area fill — so you see not just where your mood was, but how stable or volatile that period was. The heatmap runs from red (below 0.2) to green (above 0.4). Hover any cell: date, primary emotion, top triggers, which activity was served.

AI-Powered Journal

Each entry is processed sentence by sentence, not as a whole. The specific sentences where emotional signal is strongest get surfaced. Recurring keywords cross-reference against the SurrealDB trigger graph — the system generates insight statements like "The word 'deadline' appears frequently in your low-mood entries." Summaries attach to each entry at write time.

Gamified Wellness — Matched to Current Mood

Each activity maps to a mood range. A user in active distress gets the breathing exercise — a spring-animated circle on a 4-second inhale–hold–exhale cycle — not the drag-and-drop game. The gratitude challenge has daily prompts and streak tracking. The positivity feed only surfaces when the mood trend is already turning upward — reinforcing the arc, not manufacturing it.

09 — Where It Still Falls Short

Being honest about limitations is more useful than papering over them.

Low-light facial detection drops to ~82%. Most people use wellness apps in the evening, in dimly lit rooms — exactly when accuracy falls. When face detection fails, weight redistributes to text and voice, but the lost signal can't be recovered.
Voice transcription has real blind spots. The Web Speech API gives no confidence feedback. Non-native English speakers and noisy environments are most affected. Misinterpreted speech scores silently — the user has no idea.
Single-hop queries only. Keeps things fast but prevents indirect temporal patterns. "Work stress consistently precedes social anxiety three days later" is exactly the kind of insight the graph could yield. It can't, yet.
The evaluation dataset was synthetic. Real-world emotional expression is more variable than augmented test samples. Future evaluations need real participants and longitudinal tracking.
No clinical validation. This is a research project — not a regulated medical device. It should not substitute for professional mental health support.

10 — What We'd Tell Ourselves at the Start

Five things that would have saved time, or changed how we approached a decision, if we'd known them earlier.

1. Don't force one database to do two jobs. The moment you cram relationship data into MongoDB documents, query complexity starts climbing and never stops. Draw that boundary early.

2. Browser-based ML is underrated for reach. face-api.js and Web Speech API mean zero installation friction. The accuracy tradeoff is real, but broad access often matters more.

3. Contextual signals make the predictor meaningfully better. Sleep hours, stress level, and energy level alongside mood history catches dips that pure historical averaging misses.

4. GraphQL as the API bridge keeps the frontend clean. Both databases behind one endpoint. React never needs to know about the split. Apollo caching means most data doesn't hit the network twice.

5. LLM fallback for ambiguity adds value without bloating the happy path. It only fires when the fused score is genuinely too low to classify. That specificity is what makes it a safety net, not a crutch.

11 — What We're Building Next

The current system works. But the roadmap is clear.

Replace Sentiment.js with RoBERTa. Fine-tuned on mental health conversation data. "I guess I'm fine" and "I'm fine" shouldn't score identically.
Extend Gemini to multi-turn therapeutic chains. Genuine back-and-forth dialogue with memory of earlier turns — not just a single-turn fallback.
Wearable integration. Fitbit and Apple Health for heart rate variability and sleep data — a fourth channel that's even harder to consciously manipulate.
Multilingual expansion. French, Arabic, and Hindi first. Mental health support in your first language is categorically different.
On-device TensorFlow.js personalised models. Trend models running on the user's own device. Nothing personal leaves the browser.
Real-participant evaluation. Move from augmented test samples to actual longitudinal studies. Honest benchmarks are worth more than optimistic ones.

Key Takeaways

The architectural split between SurrealDB and MongoDB is the most important decision in this project. Every other piece — the fusion logic, the predictor, the GraphQL bridge — only works well because the data is shaped correctly underneath.

→ SurrealDB for emotional memory. The User → Emotion → Trigger → Solution graph is what makes personalisation real. Without it, you have logs. With it, you have something that actually learns about a person over time.

→ MongoDB for operational data. Chat history, mood logs, journals, game streaks — document-shaped, linearly growing, and perfectly suited to aggregation pipeline analytics.

→ Django + Graphene as the unified API layer. One endpoint for the React client regardless of which database the data lives in. That boundary is what keeps the frontend maintainable as the system grows.

→ Emotion fusion across three channels. Text, voice, and face — with graceful degradation when any channel fails and Gemini for genuinely ambiguous signals.

→ Proactive over reactive. Catching a bad day before it arrives is possible when you have a real memory layer. That's the actual payoff of building this correctly.

For a wellness AI, the persistence layer isn't an implementation detail — it is the product. The quality of every recommendation is only as good as the structure of the data underneath it.

Resources

🔗 GitHub:https://github.com/honeyharshita/pfsd
Youtube Video:

Special Thanks

We would like to extend our heartfelt gratitude to our mentor, @chanda_rajkumar , for his invaluable guidance and continuous support throughout the development of Mentalwellness. His technical insights, critical feedback, and encouragement helped us shape this project.

DEV Community: BAPANAPALLI PRANEETA