DEV Community: Yuva Kunaal

"Wrong Answer" is the worst feedback you can give a SQL learner — so I built something better

Yuva Kunaal — Mon, 18 May 2026 04:16:54 +0000

You submit a query. It's wrong.

The platform says: Incorrect result.

That's it.

No diff. No hint. No explanation of which rows are wrong or why. Just a red banner telling you to try again.

I've used enough SQL learning tools to know this is the standard. And I think it's the single biggest reason people get stuck and give up — not because SQL is hard, but because the feedback loop is broken.

So when I built SQLumina, I made the debug experience the core feature. Here's exactly how it works under the hood.

The problem with "wrong answer"

When a SQL query returns incorrect results, there are maybe 15 different reasons why:

Wrong JOIN type (INNER when you needed LEFT)
Joining on the wrong columns (PK to PK instead of FK to PK)
Missing GROUP BY column
WHERE clause firing before aggregation
HAVING threshold off by one
LIKE missing a wildcard
NULL comparison written as col = NULL instead of IS NULL

Each of these produces a different shape of wrong output. A generic "incorrect" banner treats them all the same. That's useless.

What a learner actually needs is: which rows are wrong, and why.

Step 1 — Building the row-level diff

Every challenge in SQLumina has a reference solution stored server-side. When a user submits, the backend runs both queries concurrently against the live PostgreSQL database:

user_result, ref_result = await asyncio.gather(
    run_query(user_sql, schema),
    run_query(reference_sql, schema)
)

Then it computes three sets:

correct = user_rows & reference_rows
missing = reference_rows - user_rows
extra   = user_rows - reference_rows

These map directly to the three columns in the debug panel: Correct, Missing, Extra.

The diff table shows full row values — all columns, no truncation. If a row is missing because your JOIN dropped it, you can see exactly which row it was.

Step 2 — Accuracy scoring with Jaccard similarity

Once you have the three sets, you need a single accuracy number.

I use Jaccard similarity:
accuracy = |correct| / (|correct| + |missing| + |extra|)

The reason this matters: a simple "percentage correct" would reward over-fetching. If the expected result is 10 rows and you return 10,000, you'd technically have 100% of the correct rows — you'd just also have 9,990 extra ones.

Jaccard penalises both under-fetching and over-fetching. Getting 15 rows when 10 were expected is scored lower than getting exactly 10 right. This matches how production SQL correctness actually works.

Step 3 — Parsing the query AST

Showing the diff is useful. Explaining why the diff exists is what makes it genuinely educational.

This is where it gets interesting.

I built a 30+ rule heuristic engine that parses the user's actual SQL to extract:

Table names and aliases
JOIN conditions (specifically the ON clause columns)
SELECT columns and whether they're wrapped in aggregates
WHERE predicates and their operators
GROUP BY columns
HAVING conditions

Then it matches those parsed elements against the diff to produce specific diagnosis cards.

Example rule — wrong JOIN key detection:

def check_join_key(parsed, diff):
    for join in parsed.joins:
        left_col  = join.condition.left.column
        right_col = join.condition.right.column
        left_ref  = get_table_pk(join.condition.left.table)
        right_ref = get_table_pk(join.condition.right.table)

        if left_col == left_ref and right_col == right_ref:
            return DiagnosisCard(
                severity="high",
                message=f"You're joining {join.condition.left.table}.{left_col} "
                        f"to {join.condition.right.table}.{right_col}. "
                        f"Both are primary keys. You probably want the foreign key instead.",
                fix=generate_corrected_join(join)
            )

The card surfaces in the UI with a severity badge, confidence percentage, the specific columns involved, a corrected SQL fragment, and a plain-language explanation of the underlying concept.

Step 4 — The zero-rows suite

A separate set of 7 rules fires specifically when the user's query returns zero rows against a non-empty expected result. These are the most frustrating bugs to debug because the diff table is just... empty.

The rules detect:

Pattern	Issue
`col = NULL`	Should be `IS NULL`
`LIKE 'foo'`	Missing wildcard — should be `LIKE '%foo%'`
`BETWEEN hi AND lo`	Bounds are reversed
`NOT IN (...)` with NULL in list	NULL silently excludes every row
`date_col > CURRENT_DATE + INTERVAL '30 days'`	Future filter — should subtract
WHERE clause over-filtered	Too many AND conditions, no rows survive
No WHERE when one is required	Missing filter entirely

Each zero-row rule names the exact predicate from the user's query and suggests the corrected version. No generic messaging.

Step 5 — The pgBouncer bug that took me days

This one isn't about the debugger directly. It's about the infrastructure that makes sandboxed query execution reliable — and it's the bug that cost me the most time.

SQLumina runs on Neon's serverless PostgreSQL with asyncpg. Each user query runs inside a schema — ecommerce, social_media, or banking — and sandbox queries run in an isolated sandbox_{user_id} schema.

To route queries to the right schema, I was setting the search path before executing:

await conn.execute(f"SET search_path TO {schema}")
await conn.execute(user_sql)

In development: worked perfectly.

In production under any real load: randomly failing with relation "products" does not exist.

Not consistently. Not reproducibly. Just sometimes, on concurrent requests.

The root cause: Neon uses pgBouncer in transaction mode.

In transaction mode, pgBouncer doesn't guarantee that two consecutive statements from the same application connection hit the same backend PostgreSQL connection. The SET search_path runs on connection A. The actual query lands on connection B — which has a fresh search path pointing at public, where your tables don't exist.

The fix:

async with conn.transaction():
    await conn.execute(f"SET LOCAL search_path TO {schema}")
    await conn.execute(f"SET LOCAL statement_timeout = '5000'")
    result = await conn.fetch(user_sql)

SET LOCAL scopes the change to the current transaction. Since the transaction is atomic, both statements are guaranteed to execute on the same backend connection. pgBouncer can't split them.

Two lines. Took days to find. Now it never fails.

If you're building on Neon and hitting "relation does not exist" errors randomly under load — this is your fix.

Step 6 — Sandboxing safely

A few things that keep user queries from doing damage:

Comment stripping — SQL comments (-- and /* */) are stripped before parsing so users can't hide keywords inside comments to bypass validation.

Destructive operation blocking — DROP DATABASE, TRUNCATE outside sandbox scope, and GRANT are blocked at the parser level before execution.

Auto-LIMIT — LIMIT 1000 is appended when absent so a SELECT * on a large table doesn't flood the frontend.

Timeout — SET LOCAL statement_timeout = '5000' kills queries at the DB level after 5 seconds. A Python asyncio.wait_for at 6 seconds is a belt-and-suspenders fallback — PostgreSQL cancels cleanly before Python times out, which prevents dirty pool connections.

Read-only enforcement — The main ecommerce, social_media, and banking schemas are strictly read-only from the Playground. Only the user's own sandbox schema allows DML.

Per-user isolation — Every user gets their own sandbox_{user_id} schema. Other users' tables are completely invisible. Schema names are case-folded and sanitised before interpolation so two Clerk IDs that differ only in case can never collide.

What I learned

Building this taught me more SQL than taking any course did.

You can't write a rule that detects "you're joining on two primary keys" without understanding deeply why that's wrong and what the correct foreign key relationship should look like. You can't write the zero-rows suite without knowing every way a query can silently exclude all its data.

The debug engine is now 30+ rules. It's also the thing I'm most proud of in the entire codebase.

If you're building anything where users write queries against real data — especially in a learning context — invest in the feedback layer before anything else. The SQL execution part is easy. Telling someone specifically what they got wrong is the hard problem.

SQLumina is about to launch...

CommitAI — Local AI-Powered Git Assistant Using Gemma 4

Yuva Kunaal — Fri, 08 May 2026 20:56:09 +0000

This is a submission for the Gemma 4 Challenge: Build with Gemma 4

What I Built

As developers, we repeatedly write commit messages, maintain changelogs, and switch context during development. I wanted to build a lightweight developer tool that could automate this workflow completely offline without relying on cloud APIs or external AI services.

So I built CommitAI — a local AI-powered Git assistant using Gemma 4 + Ollama.

The workflow is simple:

Read staged Git diff
Send it to a local Gemma 4 model
Generate a clean Conventional Commit message
Update changelog automatically
Execute the Git commit

I also added Git hook integration so the workflow becomes:

git add .
git commit

and the AI handles the rest.

The project is built entirely in Python and runs locally on my MacBook Air M2 (8GB RAM).

Features

AI-generated Conventional Commit messages
Automatic changelog generation
Git hook integration
Fully local/offline workflow
Rich CLI interface using the Rich library
No external APIs
Privacy-friendly local inference
Uses staged Git diffs as context

Demo

Demo Video

Code

CommitAI Repo

How I Used Gemma 4

I used the gemma4:e2b model through Ollama for all AI-powered functionality inside CommitAI.

I specifically chose the E2B model because:

it runs efficiently on local hardware
lightweight enough for my MacBook Air M2 with 8GB RAM
low-latency responses for CLI workflows
strong enough reasoning for summarizing Git diffs
ideal for privacy-focused offline tooling

Gemma 4 powers:

commit message generation
changelog summarization
Git workflow automation

Architecture

Git Diff
   ↓
CommitAI
   ↓
Ollama API
   ↓
Gemma 4 (E2B)
   ↓
AI-generated commit/changelog
   ↓
Git commit execution

Tech Stack

Python
Ollama
Gemma 4 (gemma4:e2b)
Rich
Git Hooks

Future Improvements

PR description generation
Multi-model support
Better diff summarization
VSCode extension
Team changelog modes
Interactive commit editing

One of my biggest goals with this project was proving that useful AI developer tooling can run fully locally without depending on cloud APIs.

Thanks for reading 🚀

I built a free AI Flowchart Studio — just launched today! 🚀

Yuva Kunaal — Fri, 08 May 2026 18:27:40 +0000

Hey DEV community! 👋

Just launched AI Flowchart Studio today — a tool that converts
plain English into professional flowcharts using a Multi-Agent
Gemini AI pipeline.

The Problem

Existing tools like Lucidchart are too heavy for quick diagrams.
I wanted something where you just DESCRIBE and it builds.

How the AI Works (4-Stage Pipeline)

This is the part I'm most proud of:

Orchestrator Agent — Validates if the prompt can logically become a flowchart
Logic Parser Agent — Breaks text into a structured JSON graph (nodes + edges)
Generator Agent — Converts the graph into Mermaid.js syntax
Syntax Validator — Final check to guarantee perfect visual output

This pipeline ensures "Garbage In" never becomes "Garbage Out" 🎯

Tech Stack

Frontend: Vanilla JS, Mermaid.js, html2canvas, CSS3
Glassmorphism — deployed on Vercel

Backend: FastAPI (Python), Google GenAI SDK,
Server-Sent Events for real-time streaming — deployed on Render

Key Features

🤖 Multi-Agent AI generation
✏️ Manual builder (click & type, no coding)
🔄 Undo/Redo engine with memory buffer
📤 Export PNG (3x super-scaled), SVG, or Mermaid code
💾 5 concurrent saved projects
📱 Mobile-responsive with bottom-sheet menus
🔍 Hardware-accelerated canvas zoom (+/- 300%)
🔑 BYOK — your API key never leaves your browser

Privacy First (BYOK)

Your Gemini API key is stored only in your browser's
LocalStorage. Our backend acts purely as a secure proxy —
zero data retention.

🔗 Try it: AI Flowchart Studio

🚀 Also live on Product Hunt today — support appreciated!
Product Hunt Launch

Would love feedback from devs:

What would make you use this daily?
Any architecture improvements you'd suggest?
Would you pay for a hosted version (no API key needed)?

Thanks for reading! 🙏