The Plan for Entity Framework Core 6.0
Today we are excited to share with you the plan for Entity Framework Core 6.0.
This plan brings together input from many stakeholders and outlines where and how we intend to invest for the Entity Framework (EF Core) 6.0 release. This plan is not set-in-stone and will evolve as we work on the release based on what we learn. This learning includes feedback from people like you, so please let us know what you think!
IMPORTANT This plan is not a commitment. It is a starting point that will evolve as we learn more. Some things not currently planned for 6.0 may get pulled in. Some things currently planned for 6.0 may get punted out.
EF Core 6.0 is the next release after EF Core 5.0 and is currently scheduled for November 2021 at the same time as .NET 6. EF Core 6.0 will align with .NET 6 as a long-term support (LTS) release.
EF Core 6.0 will likely target .NET 6 when released. It is unlikely to support any .NET Standard version. It will not run on .NET Framework. See the future of .NET Standard for more information.
Highly requested features
As always, a major input into the planning process comes from the voting (👍) for features on GitHub. For EF Core 6.0 we plan to work on the following highly requested features:
- SQL Server temporal tables
- Allow temporal tables to be created via Migrations, as well as allowing access to historical data through LINQ queries.
- JSON columns
- Introduce common patterns for JSON support that can be implemented by any database provider.
- JSON column support will be implemented for SQL Server and SQLite. (Note that the PostgreSQL and MySQL providers already support JSON columns.)
- Allow arbitrary ordering of columns when creating a table with Migrations or
- Allow arbitrary ordering of columns when creating a table with Migrations or
While EF Core is generally faster than EF6, there are still areas where significant improvements in performance are possible. We plan to tackle several of these areas in EF Core 6.0, while also improving our perf infrastructure and testing.
- Performance infrastructure and new tests
- Improve the infrastructure for performance tests as well as adding new tests and fixing low-hanging fruit.
- Compiled models
- Compiled models will improve startup performance, as well as having generally better performance when accessing the model.
- TechEmpower Fortunes
- We plan to match Dapper performance on the TechEmpower Fortunes benchmark. (This is a significant challenge which will likely not be fully achieved. Nevertheless, we will get as close as we can.)
- We will continue investigating in making EF Core work better with linkers and AOT. We do not expect to fully close the gap in the 6.0 timeframe, but we hope to make significant progress.
Migrations and deployment
Following on from the investigations done for EF Core 5.0, we plan to introduce improved support for managing migrations and deploying databases. This includes two major areas:
- Migrations bundles
- Migrations bundles will provide a simple, robust mechanism for deploying EF Core migrations.
- Managing migrations
- We plan to improve the tools and project/assembly management for EF Core migrations.
Improve existing features and fix bugs
- EF6 query parity
- We plan to close the query gap to EF6 and make supported EF Core queries a true superset of supported EF6 queries.
- Value objects
- We plan to introduce a better experience focused on the needs of value objects in domain-driven design.
- This approach will be based on value converters rather than owned entities which have proved not to be a good fit.
- Cosmos database provider
- We are actively gathering feedback on which improvements to make to the Cosmos provider in EF Core 6.0; please make sure to vote (👍) for the Cosmos features that you need.
- Expose model building conventions to applications
- Model building conventions are currently controlled by the database provider. In EF Core 6.0, we intend to allow applications to hook into and change these conventions.
- Zero bug balance (ZBB)
- We plan to fix all outstanding non-blocked bugs during the EF Core 6.0 timeframe.
- Miscellaneous smaller features
- Split query for non-navigation collections
- Detect simple join tables in reverse engineering and create many-to-many relationships
- Complete full/free-text search on SQLite and SQL Server
- SQL Server Spatial Indexes
- Mechanism/API to specify a default conversion for any property of a given type in the model
- Use the new batching API from ADO.NET
The EF Core team also works on several related but independent .NET Data technologies. In particular, we plan to work on:
- Enhancements to
- Implementation of the new batching API
- Continued work with other .NET teams and the community to understand and evolve ADO.NET
- Standardize on
DiagnosticSourcefor tracing in
- Enhancements to
- Connection pooling
- Prepared statements
- Nullable reference types
- We will annotate the EF Core code to use nullable reference types.
Experiments and investigations
The EF team is planning to invest time during the EF Core 6.0 timeframe experimenting and investigating in two areas. This is a learning process and as such no concrete deliverables are planned for the 6.0 release.
- An experiment in collaboration with the community to determine what potential there is modern .NET features in a highly performant SQL Server driver.
- We plan to investigate the space and collaborate with the community to find ways to improve the experience of using GraphQL with .NET.
Find out more
This post is a brief summary of the full EF Core 6.0 Plan. Please see the full plan for more information.
Your feedback on planning is important. The best way to indicate the importance of an issue is to vote (👍) for that issue on GitHub. This data will then feed into the planning process for the next release.
In addition, please comment on this post if you believe we are missing something that is critical for EF Core 6.0, or are focusing on the wrong areas.
I for one have been very pleased w/ EFcore 5.0 and have been able to work a bunch of magic without much effort/friction. It has been extremely satisfying to enable “Microsoft.EntityFrameworkCore.Database.Command”: “Information” logging and see all the SQL that I didn’t have to write with each page load. It runs extremely fast, too. Usually all under or at 1ms.
Unicorn, indeed. Very appreciative of all your efforts out there. Looking forward to 6.0.
Exciting News!! Looking forward Entity Framework Core 6.0+ 😁.
Thanks for clear communications;
Dapper, isn’t really considered as an “ORM” but more like a Data Mapper, and that’s why it doesn’t have many features of EF as a full fledged ORM.
Dapper shines where you need to call an SP and get a dataset quickly without doing much code execution in the .Net layer. You make a call to SP and you get a collection back.
My question & suggestion is that, is it possible to make EF to act in a very light weight “Data Mapper” like Dapper by giving EF certain commands or options, that EF acts more like Dapper, in cases where we just need to get a collection fast?
I have seen, in many cases, devs have to combine these two systems and I think all data interactions within an app to DB should be governed by EF, than another system like Dapper changes data in DB where EF has no knowledge of changes.
Hi, Ben. The goals under “performance” address this. It is absolutely part of the EF Core 6.0 plan.
A question for clarification: are you looking only to match the performance of Dapper? Or are you also looking to create a ‘Dapper-like’ functionality as part of EF? Like one could use EF as little like Dapper or full-fledged EF with it handling all the SQL, etc?
Still no bulk operation support… 🙁
Entity Framework needs built int multitenant support and not through database operation interceptors.
Entity Framework should have an attribute for an object that lets me specify the primary key and the tenant id and let me EASILY filter results by tenant
I’ve implemented three systems with Entity Framework and multitenant and paid considerable extra time and money to my consultants for this missing feature.
Using different databases one per tenant does not work for us – huge maintenance cost
Using database interceptors to filter queries does not work for – huge maintenance cost
Using other hack methods does not work for us – too buggy – too costly to bring in new developers – to costly to triple check every developer’s code on every commit
Using a filtered view per tenant will not work for us – huge maintenance cost
Using attributes embedded in the SQL Server connection in .net wont work for us
HIPPA compliant medical information needs a decent top tier solution and not a set of hacks for multitenant support.
Our system, for example, has 400 tables and over 1000 queries.
I’m curious to know what your design for a “non hack method” is. There are several potential approaches and all seem to have caveats and trade-offs. We are tracking the documentation of approaches in issue #96 and can turn that into a feature issue if there is a viable solution that involves changes to the software. Do you mind sharing your thoughts on GitHub and we’ll continue the conversation there? Thanks!
Wouldn’t partitions make sense here? You create a partion key on the tenant id of the record and then your queries only return records within that partion.
Hey, “match Dapper performance” would be really awesome!
Disappointing plan. Nothing I want to see
Seems like more like maintenance.
Leading into LTS I wouldn’t expect a lot of new stuff.
There is one very big feature I miss. The changetracker should have weak references to entities that are unchanged or detached. That way you would not need so shortlived dbcontext’s because you get rid of the memory leaks. It has been a very big issue since the start. The other thing is better support for bulk update queries directly on DbSets to also update tracked entities. Default should be nontracking on queries.
So the requests for Visual Studio tooling keeps being ignored, back to EF 6.
Telling us that payed for Visual Studio Professional for such features, to go look around alternatives is no answer.
Probably the wrong place for this question….
Will we ever get support for C# Stored Procs in Azure SQL? This seems like something that would enable EF Core to communicate directly with procs running in the Database and would be blindingly fast. You could create a proc with a persistent bidirectional socket to a DbContext that would allow for streaming data on demand in Desktop applications.