Explores what LINQ actually is—a query pattern paired with provider-specific translation—rather than a universal query language. LINQ to Objects and LINQ to XML feel seamless because they operate on similar tree/collection math, while LINQ to Entities (EF Core) leaks abstraction because it bridges C#'s imperative model with SQL's declarative, set-based one, sometimes silently falling back to expensive client-side evaluation or generating suboptimal SQL. A practical framework is offered: use LINQ as glue for in-memory work, learn the native query language for heavily-used formats, treat translation failures as signals, and don't force graph or other non-object-shaped queries through LINQ. The piece closes by noting vector embeddings are producing a new query primitive—similarity search—and that .NET tooling like Semantic Kernel is attempting the same unification trick LINQ did, with success still an open question.
Table of contents
What LINQ Actually PromisesWhere the Abstraction LeaksA Practical FrameworkA New Format Is Already Repeating the PatternWhere This Leaves YouQuestions this post answers
Why does my EF Core LINQ query suddenly get much slower on large tables even though it looks fine in code?
It likely fell back to client-side evaluation, where EF Core cannot translate part of the LINQ expression into SQL and instead pulls the entire table into memory before filtering it in C#. This can happen with custom C# methods, complex string manipulation, or certain LINQ operators used in the wrong position, and the query often looks identical to a well-translated one in source code while behaving completely differently under real data volume. Developers debugging EF Core performance regressions can find deeper LINQ and SQL translation breakdowns on daily.dev.
When should I avoid using LINQ and query a database in its native language instead?
Use LINQ as a glue layer for in-memory, list-and-object-shaped work, but learn the native query language for any format queried heavily, such as SQL for EF Core or Cypher and Gremlin for graph databases. Forcing a naturally graph-shaped query through LINQ-to-Objects after loading everything into memory defeats the purpose of using a graph database, so native queries should be used directly for non-object-shaped data. Teams weighing LINQ against native query languages can compare trade-offs and patterns on daily.dev.
What makes querying vector databases different from querying SQL or document databases with LINQ?
Vector databases like Pinecone, Qdrant, and Azure AI Search store data as high-dimensional numerical vectors and use similarity search, such as cosine similarity or nearest-neighbor search, rather than equality filtering or path traversal. This is a fundamentally new query primitive—finding vectors closest to a given one—distinct from SQL's WHERE, XPath's tree descent, or GraphQL's relationship traversal, and .NET tools like Semantic Kernel are building new abstractions around it. Developers evaluating vector search tooling can track how these emerging abstractions evolve on daily.dev.
56.6K Impressions1 Comment