QueryHeal: The Carbon-Aware ORM Optimizer

A real-time .NET interceptor that detects N+1 anomalies, provides smart code fixes, and prevents wasted CPU cycles to reduce data center carbon footprints.

Comment

Inspiration

Working extensively with C# and Entity Framework Core, I noticed a recurring, silent performance killer in modern backend architectures: the N+1 query anomaly. Developers often prioritize rapid feature delivery, inadvertently writing LINQ queries that hit the database inside loops.

But this isn't just a performance issue; it is an environmental one. Every redundant database round-trip consumes unnecessary CPU cycles, memory allocations, and ultimately, electricity. I wanted to build a tool that bridges the gap between "Code Optimization" and "Green Computing" at the runtime level.

What it does

QueryHeal Sentinel is an intelligent, low-latency runtime middleware for Entity Framework Core. It acts as a "Green Guardian" for your database:

  • Real-time Interception: Hooks directly into EF Core's pipeline to monitor SQL commands on the fly.
  • Anomaly Detection: Uses thread-safe tracking to identify N+1 loops executing within a tight time window.
  • Smart Suggestion Engine: Instead of just throwing an error, it analyzes the SQL AST/string, extracts the entity relationships, and suggests the exact C# code fix (e.g., adding .Include()).
  • Carbon Footprint Visualization: Calculates the wasted CPU latency and potential carbon emissions, broadcasting these metrics via SignalR to a live Web Dashboard.

How we built it

The core engine is built purely with C# and .NET 8, leveraging high-performance, low-allocation techniques to ensure the interceptor itself doesn't become a bottleneck.

To calculate the environmental impact, I implemented a heuristic cost model. If \(N\) is the number of identical queries executed within the time window \(T\), the redundant query count is \(R = N - 1\). The estimated carbon footprint \(E_{co2}\) is calculated as:

$$ E_{co2} = R \times C_{q} $$

Where \(C_{q}\) represents the estimated carbon emission constant per single query execution.

For the real-time visualization, I integrated SignalR into the .NET backend to push events seamlessly to a lightweight, vanilla HTML/JS/CSS frontend, avoiding heavy frontend frameworks to keep the demo crisp and fast.

Challenges we ran into

The biggest technical hurdle was the "Observer Effect"—monitoring the system without degrading its performance. Injecting complex string parsing (Regex) on the hot path of database calls risked adding latency. To solve this, I optimized the interception logic using ConcurrentDictionary, Span<T>, and non-blocking asynchronous event publishing so the main thread never waits for the UI to update.

Accomplishments that we're proud of

  • [x] Successfully hooking into EF Core's deepest pipeline without causing runtime crashes.
  • [x] Building a full-stack, real-time analytics system (Backend Interceptor + SignalR + Web Dashboard) in a solo effort within the hackathon timeframe.

  • [x] Proving that algorithmic optimization directly translates to tangible environmental sustainability.

    What we learned

    Building this project solo pushed me to explore the deepest layers of the .NET ecosystem and rethink how software interacts with hardware:

  • EF Core Internals: I learned how to successfully hook into Entity Framework Core's command execution pipeline using DbCommandInterceptor without disrupting the application's natural lifecycle.

  • High-Performance C#: I discovered the critical importance of zero-allocation code on the "hot path". Using Span<T> for string manipulation and Environment.TickCount64 for tracking time—instead of the standard DateTime.Now—was essential to keep the interceptor's overhead under 1 millisecond.

  • Real-time Event Driven Architecture: I learned how to seamlessly bridge low-level backend database events with a real-time frontend dashboard using SignalR.

  • Green Computing Mindset: Most importantly, I realized that as developers, our code has a physical footprint in the real world. Optimizing a single database query doesn't just save milliseconds of latency; it saves watts of electricity, translating directly into a greener planet.

    What's next for QueryHeal: The Carbon-Aware ORM Optimizer

  • NuGet Package: Packaging the middleware into a standard library so developers can plug it into any .NET architecture with services.AddQueryHealInterceptor().

  • AI Log Analytics: Exporting the anomaly data to a background worker where a Small Language Model (SLM) can analyze complex query patterns over time and suggest database index creations.

Built With

Share this project:

Updates

Submission history