snorql

TL;DR

• I conceived snorql and led the team that built it into Udaan’s first open-source project — see the source code, engineering blog, Udaan Tech Talks case study, and Rootconf session.
• Workload visibility enabled right-sizing, helping reduce Azure database costs by 75%.
• Teams could find and fix bad queries before it was too late, instead of discovering them through customer-facing latency and timeouts.
• Index tuning became evidence-led, with clear utilisation data and visibility into redundant or unused indexes.
• Proactive alerts prevented hundreds of degradations and potential outages before customers were affected.

The problem

Database incidents at Udaan depended too heavily on specialist knowledge. Useful SQL Server diagnostic queries lived across personal scratch files and notes. During an incident, engineers had to remember which queries to run, correlate several result sets, and know enough database internals to turn the output into an action.

A shared document improved discovery, but not the workflow. As the query library grew, it became another place to search. It could not orchestrate related checks, clean up noisy results, or explain what to do next.

What we built

I came up with the idea for snorql and led the team that created it: an extensible platform for turning SQL diagnostics into reusable, actionable metrics. My role spanned product direction, framework design, the metric roadmap, and adoption across engineering teams.

The project separated the common lifecycle of a metric — configuration, input, execution, post-processing, recommendations, and persistence — from database-specific implementations. Teams could plug in their own connection and storage layers, then add a metric through a consistent interface rather than building another one-off script.

It shipped as two modules:

• snorql-framework provided the database- and driver-agnostic interfaces and execution model.
• snorql-extensions packaged production-ready SQL Server diagnostics for active and long-running queries, blocking hierarchies, DDL activity, database and table growth, index utilisation, and unused indexes.

We put a dashboard over these capabilities so engineers could investigate common failure modes on demand without first becoming SQL Server experts.

What it changed

The most important result was not another monitoring dashboard. snorql encoded hard-won operational knowledge into a tool the wider engineering organisation could use.

Looking at database health, query performance, and index utilisation became straightforward for application teams. Engineers could identify expensive or long-running queries, trace blocking chains, inspect active DDL, understand abnormal database growth, and act on concrete recommendations without waiting for a database specialist.

Index optimisation became especially practical. Teams could see which indexes were actually being used, find redundant or unused indexes, and tune high-impact indexes based on workload evidence. That reduced unnecessary storage and write overhead while improving query performance.

The same diagnostics powered proactive alerts. Instead of discovering trouble only after customer-facing latency or timeouts appeared, teams could respond to blocking, runaway queries, growth anomalies, and resource pressure earlier. This prevented hundreds of system degradations and potential outages.

snorql also gave us the usage evidence needed to right-size databases rather than overprovision them defensively. As part of the broader database reliability and optimisation programme I led, this work reduced Azure database spend by 75% over two years — millions in annual savings — while the business continued to grow.

Sharing the work

I wrote the engineering article snorql — diagnosing databases like a boss to explain the problem, architecture, and the production use cases that shaped it.

The video above is a Udaan Tech Talks case study in which my teammates and I discuss snorql, SQL monitoring, and what we learned from operating it in production.

I also spoke about the project and Udaan’s database cost-optimisation journey at Rootconf’s The battle of scale versus costs. The conference session covered cloud offering selection, database maintenance, index and query optimisation, and the tool-first approach that made those practices repeatable.

The source code is available under the Apache 2.0 license. The repository was archived by Udaan in 2026 and remains available as a record of the framework and its metric library.