EFCore.Visualizer: reading an EF Core query plan from the debugger

A query plan without leaving the debugger

EFCore.Visualizer is described as an Entity Framework Core queries debugger visualizer, and its one job is to show you the query plan of your queries directly inside Visual Studio.

The workflow is short. After installing the extension from the marketplace, a new debugger visualizer is added to Visual Studio. When you are debugging and hover over a query, an option appears to view the query plan, and clicking on Query Plan Visualizer displays it.

There is a detail in the documentation that changes how you should think about the tool. The documentation notes that what is shown is the actual query plan, which means it forces query execution. This is not a free preview of a plan the database cached from a previous run. The query runs when you ask to see its plan, which is exactly what you want during a debug session, because the plan you see corresponds to the state of the database at that moment, and it is exactly what you do not want if the query is expensive or has side effects.

The audience is a .NET developer sitting in front of a slow query, and the value proposition is that the plan appears in the same window as the code instead of in a separate management studio where you would have to paste the generated SQL by hand.

The extension is published on the Visual Studio Marketplace under the name GiorgiDalakishvili.EFCoreVisualizer, and the licence is GPL-3.0, which is worth noting because most Visual Studio extensions in the marketplace carry a more commercial licence.

Five database engines, and the same plan layout in each

The visualizer supports SQL Server, PostgreSQL, SQLite, MySQL and Oracle, and the repository carries example screenshots for each of them, with the SQL Server and MySQL examples shown in both a dark and a light mode.

The support is not a thin wrapper over a single plan format. Each engine has its own plan shape, and the documentation shows them side by side: a SQL Server plan with its own operator tree, a PostgreSQL plan, a SQLite plan, a MySQL plan, and an Oracle plan. The Oracle example is described in the documentation as including Actual IO stats, Outline data, Projections and Predicates, which is the level of detail the Oracle plan format carries and the others do not.

That last point is the one to think about before you commit. A query plan is not a portable artefact. It is a description of what one database engine decided to do, expressed in that engine's vocabulary, with the operators, cost estimates and statistics that engine reports. Reading a SQL Server plan tells you about index usage and estimated row counts in SQL Server. The equivalent information for Postgres is in a different document with different fields, and the two are not interchangeable even when the SQL underneath them is the same.

So the practical value of the extension is that you read the plan in the shape your engine actually produces, without translating it. For a team running more than one engine, that means the tool is genuinely useful rather than a convenience, because a plan scraped from a log and pasted into a separate viewer is a plan in the wrong dialect.

The rendering itself is not written from scratch. The extension uses pev2 for the PostgreSQL plan visualisation, html-query-plan for the SQL Server side, and Treeflex for the tree layout, all three credited in the documentation.

The Visual Studio and EF Core version floor, and why it exists

The requirements are stated in an IMPORTANT note in the documentation and they are not negotiable. The visualizer requires Visual Studio version 17.9.0, released on February 13th 2024, or newer, and it supports EF Core 7 or newer.

That floor is a consequence of how the extension works. It hooks into the debugger as a visualizer, and the debugger visualizer API in Visual Studio is what gives it a window to render the plan in and a way to be invoked from a hover over a variable. A debugger visualizer is a Visual Studio extension point, and that extension point changed over time, so an extension built against a recent one cannot be loaded into an older Visual Studio.

The EF Core 7 floor is the same kind of constraint from the other direction. To get the query plan, the extension has to reach into what Entity Framework Core actually sent to the database, and the internal API for that has changed across versions. Starting at EF Core 7 is where the extension's author found the seam to be stable enough to build on.

The practical consequence for an adopting team is that the visualizer is a tool for a specific era of your stack, not a universal one. If your organisation is still on Visual Studio 2022 before 17.9, or on EF Core 6, the extension is simply not installable, and the fallback is what the documentation implies as the manual route: capture the generated SQL, run it in the engine's own tooling, and read the plan there. That route still works and it is what the extension is automating.

The documentation also links a video of the extension in the Visual Studio Toolbox, which is the fastest way to see the hover-and-click flow before installing anything.

The two known issues you will hit, and the workarounds

The documentation lists two known issues, and both are the kind that cost an afternoon if you meet them without warning.

The first is a timeout. If query plan extraction takes more than five seconds, you get an evaluation timed out error. The fix is implicit in the design: the extraction actually runs the query, so a query that takes longer than five seconds to execute or to plan will not produce a plan. A query with a slow join, a large scan or a bad plan is precisely the query you most want to inspect, and it is the one most likely to time out. The README links the issue tracker entry for this.

The second is more awkward. If your project uses Application Insights, you might get a cannot evaluate expression since the function evaluation requires all threads to run error when viewing the query plan. The documented workaround is to disable Application Insights when running your project with a debugger attached.

That workaround is the real cost of this tool. The evaluation has to happen on the thread you are inspecting, and the debugger's expression evaluation model conflicts with Application Insights' instrumentation. The fix is not a configuration tweak but a change in what you run while debugging, which means the setup where you reproduce the problem is not quite the setup where you measure it.

Both issues are recorded as issues on the repository rather than described as design limitations, which is worth noting in itself. The project publishes no GitHub releases, so the issue tracker is the only place this information accumulates, and the last push to the repository was on 2026-09-21.

Where EFCore.Visualizer is the wrong choice

The first limitation is the same one that applies to any debugger-time tool, and this one states it explicitly: viewing the plan forces the query to execute. That rules out a whole class of use. You cannot inspect the plan of a query that mutates data and then run the application for real, because opening the plan has already run the mutation. You cannot inspect the plan of a query whose parameters only exist in production, because you do not have those values. And you cannot use it as a monitoring tool for a live system, since the extension lives in the Visual Studio debugger rather than in the application.

The second is that the tool only knows about EF Core. If a query comes from a raw ADO.NET command, from a stored procedure, or from a Dapper-style micro-orm, the extension has nothing to hook into. The EF Core versions in your application and the queries in your code are the boundary of what it covers.

The third is the GPL-3.0 licence. For a Visual Studio extension, that is unusual, and it is a distribution constraint rather than a technical one. It is fine for internal use on a work machine, and it becomes a question to answer before you vendor the extension or redistribute it.

The fourth is that the plan is rendered by a tree layout in a window, which is the right thing for reading a plan and the wrong thing for comparing two of them. There is no diff, no history and no way to attach a plan to a ticket from inside the extension. If your team's habit is to paste a plan into an issue and discuss it, the extension gives you the plan in a convenient place but not a way to share it.

The fifth is the version coupling already described. This is an extension tied to a Visual Studio release and an EF Core generation, and both of those move. When the debugger visualizer API changes again, this extension has to change with it, and the repository's release history gives no way to plan for that.

Editorial conclusion

EFCore.Visualizer fits a .NET developer debugging a slow EF Core query locally who wants the plan without leaving the debugger, since the plan is rendered in a window next to the code and the extension supports the five database engines a typical EF Core application runs on. It is the wrong choice if you need production query plans, if your team is on EF Core 6 or earlier, or if a five second query timeout is a problem for your workload. Before installing it, check that your Visual Studio is 17.9 or newer and that the project targets EF Core 7 or newer, and note that the last push was on 2026-09-21 with no tagged releases in the repository, so the marketplace listing is what you actually install.

Frequently asked questions

Official sources

1. Giorgi/EFCore.Visualizer on GitHub
2. Issues
3. License: GPL-3.0
4. Project website
5. README