Hot Chocolate vs graphql-dotnet in .NET: Which GraphQL Library Should Your Team Use in 2026?

When your ASP.NET Core team decides to adopt GraphQL, the library choice is one of the first decisions that locks in your architecture for years. Two libraries dominate the .NET ecosystem: Hot Chocolate from ChilliCream and graphql-dotnet, the original community-maintained library. Both implement the GraphQL spec. Both integrate with ASP.NET Core. But they make very different trade-offs, and picking the wrong one for your team creates real maintenance pain.

🎁 Want implementation-ready .NET source code you can drop straight into your project? Join Coding Droplets on Patreon for exclusive tutorials, premium code samples, and early access to new content. 👉 https://www.patreon.com/CodingDroplets

What Is Hot Chocolate?

Hot Chocolate is the flagship GraphQL server from ChilliCream, a company built around the .NET GraphQL ecosystem. Originally open-source and community-driven, it has evolved into a professionally maintained library with regular releases, strong ASP.NET Core integration, and support for the full GraphQL specification including subscriptions, schema stitching, and federation.

Hot Chocolate is the most spec-compliant and actively benchmarked GraphQL library for .NET. It builds on top of ASP.NET Core's routing and middleware pipeline natively, and it integrates with EF Core through a dedicated HotChocolate.Data.EntityFramework package that can translate GraphQL filter/sort/pagination inputs directly into LINQ queries. For teams building data-rich APIs, this integration removes a substantial amount of boilerplate.

Key characteristics of Hot Chocolate:

• Schema-first and code-first approaches supported
• First-class DataLoader support for solving the N+1 query problem
• Deep EF Core integration via IQueryable projection
• Built-in support for subscriptions over WebSockets and Server-Sent Events
• Schema federation and stitching for microservices
• Active release cycle aligned with .NET LTS milestones

What Is graphql-dotnet?

graphql-dotnet is the original GraphQL library for .NET, predating Hot Chocolate and built by the community. It maps closely to the reference JavaScript implementation, which makes it familiar to developers who have used graphql-js. The library supports queries, mutations, and subscriptions, and has a large number of community packages built around it.

graphql-dotnet's strength is its familiarity and its large existing ecosystem. Teams that have invested in graphql-dotnet integrations, custom scalars, or type registrations will find the library's API predictable and stable. However, the release cadence has historically been slower, and enterprise features like schema federation and EF Core integration are not first-class citizens.

Key characteristics of graphql-dotnet:

• JavaScript-like API familiar to multi-stack teams
• Mature and stable with a large community
• Supports code-first and schema-first approaches
• Subscriptions via WebSockets
• No built-in DataLoader (requires third-party integration)
• Slower release cycle, fewer first-party integrations

Side-by-Side Comparison

Feature	Hot Chocolate	graphql-dotnet
ASP.NET Core integration	Native, deep	Standard middleware
EF Core integration	First-class	Manual resolver wiring
DataLoader (N+1 prevention)	Built-in	Third-party or manual
Schema federation	Yes (Federation v1 and v2)	Partial / third-party
Schema stitching	Yes (built-in)	Not built-in
Subscriptions	WebSockets + SSE	WebSockets
GraphQL spec compliance	High (passes kitchen sink tests)	Lower (some spec edge cases fail)
Release cadence	Active (monthly/quarterly)	Slower
Documentation quality	Extensive official docs	Community-maintained
Learning curve	Moderate (ChilliCream patterns)	Lower (familiar to JS devs)
.NET version support	.NET 8+ (LTS-aligned)	.NET 6+
License	MIT	MIT

Does Hot Chocolate Pass Spec Compliance?

This matters for teams that expose a public GraphQL API consumed by third-party clients. Hot Chocolate's team runs the full Facebook GraphQL parser kitchen sink tests as part of CI. graphql-dotnet has historically failed certain parser edge cases in those tests. For internal APIs this rarely matters. For public APIs, spec compliance determines whether standard GraphQL client tooling behaves predictably against your endpoint.

How Does the EF Core Integration Change Your Development Experience?

This is where Hot Chocolate pulls ahead for teams already using EF Core. With HotChocolate.Data.EntityFramework, you annotate your resolver return type with [UseDbContext], [UseFiltering], [UseSorting], and [UsePaging] attributes, and the library translates incoming GraphQL filter, sort, and cursor-pagination arguments directly into EF Core queries. You get database-level filtering without writing a single manual filter predicate.

With graphql-dotnet, you own the translation. You parse incoming filter arguments in your resolver, construct EF Core expressions manually, and handle pagination yourself. For a simple API this is manageable. For a data-heavy admin API or reporting layer with dozens of entities, the volume of manual wiring becomes a liability.

When Should You Choose Hot Chocolate?

Choose Hot Chocolate when:

• You are using EF Core and want filter/sort/paging out of the box
• Your API requires schema federation (microservices exposing a unified graph)
• You need schema stitching to aggregate multiple upstream APIs
• Spec compliance matters for your client tooling
• You want long-term alignment with .NET LTS releases
• Your team is building greenfield and can adopt ChilliCream patterns without migration friction

Avoid Hot Chocolate if:

• You have an existing graphql-dotnet codebase with extensive custom type registrations — migration is a rewrite, not a library swap
• Your team is small and already productive with graphql-dotnet
• You need .NET 6 support long-term (Hot Chocolate 14+ targets .NET 8+)

When Should You Choose graphql-dotnet?

Choose graphql-dotnet when:

• You are migrating from a JavaScript GraphQL backend and want API familiarity
• You have an existing graphql-dotnet codebase and no strong reason to migrate
• Your team's GraphQL usage is simple (no federation, no EF Core integration)
• You prefer a library that closely mirrors graphql-js semantics

Avoid graphql-dotnet if:

• You need DataLoaders built-in (you will wire them manually or pull in a third-party library)
• Schema federation is a requirement
• You want EF Core filter/sort/paging without boilerplate

Real-World Trade-Offs for Enterprise Teams

Team adoption curve: graphql-dotnet is easier to onboard for .NET developers who have previously worked in JavaScript stacks. Hot Chocolate has a steeper initial learning curve, but the ChilliCream documentation is more comprehensive and consistently maintained.

Schema federation in microservices: If you are building a microservices platform where each service exposes its own subgraph and you need a unified gateway layer, Hot Chocolate is the only production-grade option in the .NET ecosystem. graphql-dotnet does not support Federation v2 natively.

N+1 query risk: Both libraries expose GraphQL resolvers that can accidentally produce N+1 database queries. Hot Chocolate's built-in DataLoader pattern makes this problem easier to solve by design. In graphql-dotnet, you must add the community DataLoader package and wire it yourself. For large entity graphs, the discipline required with graphql-dotnet is higher.

Long-term maintenance signal: Hot Chocolate is backed by ChilliCream as a company with commercial offerings. graphql-dotnet is a community-maintained OSS project. Neither is at risk of abandonment in the short term, but for enterprise procurement and risk assessment, the maintenance model matters.

The Clear Winner for New .NET Projects in 2026

For new ASP.NET Core projects in 2026, Hot Chocolate is the default recommendation. It has stronger ASP.NET Core integration, better spec compliance, a first-class EF Core story, built-in DataLoaders, and active maintenance by a team that ships on .NET's release cadence.

graphql-dotnet remains a valid choice for teams with existing investment in the library or simple GraphQL requirements where the additional power of Hot Chocolate is not needed. But for greenfield enterprise APIs where federation, filtering, and long-term sustainability matter, Hot Chocolate wins.

For further reference on graphql-dotnet, see the official GitHub repository and for Hot Chocolate, the ChilliCream documentation.

---

☕ Prefer a one-time tip? Buy us a coffee — every bit helps keep the content coming!

---

Frequently Asked Questions

Is Hot Chocolate free to use in commercial .NET projects? Yes. Hot Chocolate is MIT-licensed and free for commercial use. ChilliCream offers a paid platform called Nitro for advanced schema management and IDE tooling, but the core Hot Chocolate server library has no licensing cost.

Can I use graphql-dotnet with EF Core? Yes, but integration is manual. You wire resolver return types to EF Core DbContext queries yourself. There is no built-in attribute-based filter/sort/paging translation like Hot Chocolate provides. For simple CRUD resolvers this is manageable; for complex data APIs it adds significant boilerplate.

Does Hot Chocolate support .NET 8 and .NET 10? Hot Chocolate v14+ targets .NET 8 as its minimum. It ships updates aligned with Microsoft's .NET release cadence and fully supports .NET 10. If you need .NET 6 support, you would need to stay on an older Hot Chocolate version or use graphql-dotnet.

What is the difference between schema-first and code-first in GraphQL .NET libraries? Schema-first means you write your GraphQL schema in SDL (Schema Definition Language) and then map it to your .NET types. Code-first means you define your schema using C# classes and attributes, and the library generates the SDL from them. Both Hot Chocolate and graphql-dotnet support both approaches. Hot Chocolate's code-first approach using annotations is generally considered more idiomatic for C# teams.

How does Hot Chocolate solve the N+1 query problem? Hot Chocolate has a built-in DataLoader abstraction. When multiple resolver calls need the same underlying data (for example, loading the author for each post in a list), a DataLoader batches those requests into a single database query. Without DataLoaders, each resolver call hits the database independently, resulting in N+1 queries. graphql-dotnet requires you to wire this pattern yourself using the community DataLoader package.

Can Hot Chocolate and graphql-dotnet both work with ASP.NET Core Minimal APIs? Both libraries support integration with ASP.NET Core, including Minimal APIs. Hot Chocolate's integration is more native — it plugs into the routing and endpoint middleware directly. For graphql-dotnet, integration with Minimal APIs is supported but requires more manual setup compared to controller-based configurations.

Is there a migration path from graphql-dotnet to Hot Chocolate? There is no automated migration tool. Moving between the two libraries is a rewrite of your resolver and schema registration code because the APIs are fundamentally different. The GraphQL schema itself (SDL files) is portable, but your C# implementation code is not. For large codebases, factor in significant migration effort when evaluating the switch.