--- title: One Language to Rule Them? LINQ, Abstraction, and What's... description: 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... canonical: https://daily.dev/posts/one-language-to-rule-them-linq-abstraction-and-what-s-next-mon8r0q6p twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: One Language to Rule Them? LINQ, Abstraction, and What's Next | daily.dev og:description: 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... og:url: https://daily.dev/posts/one-language-to-rule-them-linq-abstraction-and-what-s-next-mon8r0q6p og:image: https://api.daily.dev/og/posts/mon8r0q6p.png og:image:alt: One Language to Rule Them? LINQ, Abstraction, and What's Next og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # One Language to Rule Them? LINQ, Abstraction, and What's Next **[We Are .NET](https://daily.dev/sources/wearedotnet)** · 9 min read · 29 upvotes · 2 comments ## Summary 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. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### why does my EF Core LINQ query suddenly run slow even though it looks correct in C# It likely fell back to client-side evaluation, where EF Core pulls the entire table into memory and filters it in C# instead of translating the expression into SQL. This happens when a custom C# method, complex string manipulation, or certain LINQ operators can't be translated by the provider, and the failure often only shows up as a performance problem under real data volume rather than a compile or runtime error. _daily.dev surfaces EF Core and LINQ deep dives for developers chasing down query translation surprises._ ### why is EF Core generating cartesian-product joins or subqueries instead of a clean SQL JOIN EF Core's LINQ-to-SQL translator is a general-purpose engine, not a database expert, so multiple .Include() calls can produce cartesian-product joins that balloon result sets, and certain LINQ patterns generate subqueries where a human would hand-write a JOIN. This isn't a bug so much as the cost of automated translation versus schema-aware hand tuning. _track EF Core query-generation quirks and SQL translation gotchas on daily.dev before they hit production._ ### how do LINQ queries work with vector databases like Azure AI Search or Cosmos DB Vector-store abstractions such as Semantic Kernel expose a LINQ-like consistent API surface, with providers translating queries into whatever the underlying vector store needs, similar to how EF Core translates LINQ into SQL. The core operation differs fundamentally though: instead of filtering by equality, vector queries perform similarity search (e.g. k-nearest-neighbors via cosine similarity), a new grammar built around 'nearness' rather than 'match'. _developers evaluating vector search abstractions can follow how these .NET tools mature on daily.dev._ ## Community discussion Top comments from developers on daily.dev. **@jeremysylvis** · 2 upvotes > This feels very much like the complaints about EF Core/LINQ are the standard complaints made against ORMs in general, just repackaged. > > > For the majority of use cases, the generated SQL and resulting performance are perfectly fine - the benefits of working with one fairly standard, composable, language-native query interface tend to outweigh the costs of dealing with myriad query languages in their native form, especially the ergonomics clunkiness that comes with jumping from one space to the other. > > > Plus, it doesn't take much effort to opt-in to query plan generation so you can sanity-check... **@agustinbarrientos** · 1 upvotes > LINQ stays lovely until the query plan joins the conversation ## Similar posts on daily.dev - [The Many Languages of Data: How .NET Learned to Speak in Formats](https://daily.dev/posts/the-many-languages-of-data-how-net-learned-to-speak-in-formats-56sn8nk5g) · We Are .NET · 41 upvotes · 1 comments - [LINQ in C\#](https://daily.dev/posts/linq-in-c--eoxkvhpkr) · C\# Corner · 36 upvotes · 2 comments - [30 LINQ Interview Questions That Actually Get Asked in 2026](https://daily.dev/posts/30-linq-interview-questions-that-actually-get-asked-in-2026-z9bazqvrc) · Code with Mukesh · 13 upvotes · 1 comments - [From Unity Prototypes to Production Pipelines: Growing Into C\#](https://daily.dev/posts/from-unity-prototypes-to-production-pipelines-growing-into-c--puxb9vfzc) · Atomic Spin · 3 upvotes · 0 comments --- Tags: [#.net](https://daily.dev/tags/.net), [#c#](https://daily.dev/tags/c#), [#vector-search](https://daily.dev/tags/vector-search) [View this post on daily.dev](https://daily.dev/posts/one-language-to-rule-them-linq-abstraction-and-what-s-next-mon8r0q6p) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"One Language to Rule Them? LINQ, Abstraction, and What's Next","url":"https://daily.dev/posts/one-language-to-rule-them-linq-abstraction-and-what-s-next-mon8r0q6p","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/one-language-to-rule-them-linq-abstraction-and-what-s-next-mon8r0q6p"},"datePublished":"2026-08-19T12:52:58.600Z","dateModified":"2026-09-14T07:31:23.858Z","description":"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...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/54a2f6e35e748aff148f17c60eb21611?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/54a2f6e35e748aff148f17c60eb21611?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"We Are .NET","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"We Are .NET","logo":"https://media.daily.dev/image/upload/s--BsnVOa3i--/f_auto/v1718347410/logos/wearedotnet","url":"https://daily.dev/sources/wearedotnet"},"commentCount":2,"discussionUrl":"https://daily.dev/posts/one-language-to-rule-them-linq-abstraction-and-what-s-next-mon8r0q6p","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":29},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":2}],"keywords":".net,c#,vector-search","timeRequired":"PT9M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"We Are .NET","item":"https://daily.dev/sources/wearedotnet"},{"@type":"ListItem","position":3,"name":"One Language to Rule Them? LINQ, Abstraction, and What's Next"}]} {"@context":"https://schema.org","@type":"WebPage","@id":"https://daily.dev/posts/one-language-to-rule-them-linq-abstraction-and-what-s-next-mon8r0q6p","comment":[{"@type":"Comment","text":"This feels very much like the complaints about EF Core/LINQ are the standard complaints made against ORMs in general, just repackaged.\nFor the majority of use cases, the generated SQL and resulting performance are perfectly fine - the benefits of working with one fairly standard, composable, language-native query interface tend to outweigh the costs of dealing with myriad query languages in their native form, especially the ergonomics clunkiness that comes with jumping from one space to the other.\nPlus, it doesn’t take much effort to opt-in to query plan generation so you can sanity-check the SQL, dump it into your DBMS of choice for query plan analysis, etc…\nYeah, if you’re writing some incredibly performance-sensitive query and need to min-max that last bit of execution time, write raw SQL… but at least get there through legit benchmarking and performance analysis instead of prescriptive premature optimization.","datePublished":"2026-08-20T13:49:17.701Z","dateModified":"2026-08-21T13:44:34.414Z","url":"https://daily.dev/posts/mon8r0q6p#c-ZBqV3AwfB","author":{"@type":"Person","name":"Jeremy Sylvis","url":"https://daily.dev/jeremysylvis","image":"https://avatars.githubusercontent.com/u/58440072?v=4"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":2}},{"@type":"Comment","text":"LINQ stays lovely until the query plan joins the conversation","datePublished":"2026-08-20T23:39:19.889Z","url":"https://daily.dev/posts/mon8r0q6p#c-V2Bx9eVjs","author":{"@type":"Person","name":"Agustin Barrientos","url":"https://daily.dev/agustinbarrientos","image":"https://media.daily.dev/image/upload/s--5ayxQnqn--/f_auto/v1788281802/avatars/avatar_wQYYVe5Tbj0NJ7C7qPoa8?_a=BAMAMicg0"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":1}}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/one-language-to-rule-them-linq-abstraction-and-what-s-next-mon8r0q6p#faq","mainEntity":[{"@type":"Question","name":"why does my EF Core LINQ query suddenly run slow even though it looks correct in C#","acceptedAnswer":{"@type":"Answer","text":"It likely fell back to client-side evaluation, where EF Core pulls the entire table into memory and filters it in C# instead of translating the expression into SQL. This happens when a custom C# method, complex string manipulation, or certain LINQ operators can't be translated by the provider, and the failure often only shows up as a performance problem under real data volume rather than a compile or runtime error. daily.dev surfaces EF Core and LINQ deep dives for developers chasing down query translation surprises."}},{"@type":"Question","name":"why is EF Core generating cartesian-product joins or subqueries instead of a clean SQL JOIN","acceptedAnswer":{"@type":"Answer","text":"EF Core's LINQ-to-SQL translator is a general-purpose engine, not a database expert, so multiple .Include() calls can produce cartesian-product joins that balloon result sets, and certain LINQ patterns generate subqueries where a human would hand-write a JOIN. This isn't a bug so much as the cost of automated translation versus schema-aware hand tuning. track EF Core query-generation quirks and SQL translation gotchas on daily.dev before they hit production."}},{"@type":"Question","name":"how do LINQ queries work with vector databases like Azure AI Search or Cosmos DB","acceptedAnswer":{"@type":"Answer","text":"Vector-store abstractions such as Semantic Kernel expose a LINQ-like consistent API surface, with providers translating queries into whatever the underlying vector store needs, similar to how EF Core translates LINQ into SQL. The core operation differs fundamentally though: instead of filtering by equality, vector queries perform similarity search (e.g. k-nearest-neighbors via cosine similarity), a new grammar built around 'nearness' rather than 'match'. developers evaluating vector search abstractions can follow how these .NET tools mature on daily.dev."}}]} ```