Interactive REPL
db.Products.Take(5).ToList(); — history, Tab completion, :tables, :describe, :plan.
All EF roads lead to SQL.
You still own what hits the database
Entity Framework translates LINQ — it does not remove the database from your job.
My EF Vibe (efvibe) runs against your real DbContext and shows
translated and executed SQL, row counts, and query plans — so you are never guessing what EF actually sent.
.NET 8 / 9 / 10
SQL Server · PostgreSQL · SQLite · Oracle · MySQL
CLI · VS Code · efvibe serve
Apache 2.0
Why My EF Vibe is essential
There is no way around it: every EF Core query becomes SQL. An ORM buys you mapping and compile-time LINQ — not permission to stop caring about execution plans, round trips, or translated shape.
Teams discover too late that innocent-looking LINQ became N+1 calls, client evaluation, or a table scan. Production does not forgive “I thought EF would optimize that.”
My EF Vibe is the shortest path from the LINQ in your repo to the SQL on the wire — in a REPL, beside your editor, and in CI before merge.
-
See the SQL
Translated
ToQueryString()and executed commands per snippet — not after a full debug session. - Run real LINQ Your project build, your entities, your provider — not a disconnected scratchpad.
-
Prove it in CI
efvibe scanflags N+1 and performance smells before they ship. -
Explain before you tune
:planand deep scan EXPLAIN on the same SQL EF would run in production.
The old way (please stop doing this)
For years, “what SQL did EF send?” meant a scavenger hunt. It works — if you have twenty minutes and excellent scroll speed.
Before efvibe
- Turn on EF logging in
appsettings(or remember it was already on, but too noisy). - Run the application — API, auth, middleware, health checks, the works.
- Watch the logs. Miss the query. Scroll. There it is. Was that the right one?
- Copy the SQL from a wall of
infolines and parameter blobs. - Paste into SSMS, Azure Data Studio, or “that other tab you had open.”
- Run it. Tweak it. Run it again because the app used different parameters.
- Analyze the plan. Close the tool. Forget what you learned. Repeat tomorrow.
Seven context switches and a prayer. Per question.
With My EF Vibe
- Select the LINQ (or type
db.…in the REPL). - Press Run — see translated SQL, executed SQL, rows, and timing.
- Optional: Run :plan for EXPLAIN. Optional: fix the LINQ and scan in CI.
Same database truth. No app startup. No log archaeology. No copy-paste relay race.
Imagine how much time your team could have saved if every “what’s the SQL?” moment took seconds instead of
a mini sprint. That is what efvibe is for.
What teams struggle with today
LINQ is pleasant to write and painful to debug when SQL stays invisible. These are the gaps
efvibe closes.
“What SQL does this LINQ actually run?”
See executed and translated SQL per snippet, with timing and row counts — in the terminal or beside your code in VS Code.
Persistence + API split
Point -p at your EF project and -s at the startup project for user secrets and appsettings — the usual persistence + API split.
Performance smells in repositories
:scan lite and :scan deep walk your EF sources, flag N+1 and client-eval patterns, and show EXPLAIN plans on deep scan.
Gate merges on LINQ quality
Headless efvibe scan with JSON output and --fail-on severity — wire it into PR pipelines (see CI/CD guide).
Product surface
One engine — terminal REPL, efvibe serve daemon, VS Code extension, and CI scan.
VS Code extension
efvibe serve for fast Run Selection; result panel with SQL and Run Plan; Scan Review carousel for findings. Shift+Alt+E in C#.
LINQ scan
Lite heuristics plus deep scan with ToQueryString() and live EXPLAIN per call site.
Session artifacts
Scan JSON, dismissals, notes, and CSV/JSON exports under ~/.efvibe/<Project>/<DbContext>/.
