When Microsoft announced the performance numbers for .NET 8, the community lost its collective mind—specifically over Native AOT (Ahead-of-Time) compilation. The idea of deploying a C# app that starts up in 15 milliseconds and consumes barely 20MB of RAM sounds like absolute wizardry.
I’ve spent the last few months migrating a few high-traffic microservices to Native AOT. The performance gains are incredibly real, but the migration process was not a walk in the park.
Here’s the honest truth about Native AOT, when you should actually use it, and when you should stay far, far away.
The Magic of Native AOT
To understand why AOT is a big deal, you have to remember how C# normally runs. You write C#, it compiles to Intermediate Language (IL), and at runtime, the Just-In-Time (JIT) compiler translates it into machine code. JIT is brilliant because it optimizes code for the specific hardware it's running on, but JIT requires memory, and the compilation takes time (hence, cold starts).
Native AOT skips the middleman. Your C# is compiled directly into an OS-specific native binary (like C++ or Go). No runtime to install, no JIT compiler overhead.
The Good Stuff
I deployed a simple AWS Lambda function using Native AOT. The cold start dropped from ~1.2 seconds (standard .NET 8) down to 180 milliseconds. Memory usage dropped by 60%. If you are paying for serverless compute by the millisecond, Native AOT literally saves you money.
The Catch (And Why It Broke My App)
Here is the dirty secret they gloss over in the keynotes: Native AOT breaks Reflection.
Because the code is compiled ahead of time, the compiler aggressively trims away anything it thinks you aren't using to keep the binary small. If your code relies on dynamic reflection at runtime to inspect types or invoke methods, it will crash spectacularly in production with a NotSupportedException.
The System.Text.Json Nightmare
Almost all of us use System.Text.Json to serialize HTTP responses. By default, it uses reflection. If you just flip <PublishAot>true</PublishAot> in your .csproj and try to return a JSON object, it will fail.
You are forced to use Source Generators for serialization. You have to explicitly declare every single model you intend to serialize, like this:
// You have to do this for EVERY model in an AOT app
[JsonSerializable(typeof(UserDto))]
[JsonSerializable(typeof(ApiResponse<UserDto>))]
internal partial class MyApiSerializerContext : JsonSerializerContext
{
}
// And then pass it to your API configuration
builder.Services.ConfigureHttpJsonOptions(options =>
{
options.SerializerOptions.TypeInfoResolverChain.Insert(0, MyApiSerializerContext.Default);
});
It’s tedious. It adds friction to your development workflow.
Third-Party Libraries
Is your app using Dapper? Entity Framework Core? Automapper? Bad news. At the time of writing, many heavy, reflection-based ORMs and mapping libraries do not fully support Native AOT. If you are building a CRUD app with EF Core, you are probably better off sticking to standard JIT compilation.
When Should You Use Native AOT?
Do not rewrite your massive monolith in Native AOT. You will spend weeks fighting the trimmer.
Use Native AOT for:
- AWS Lambdas / Azure Functions where cold starts matter.
- Background worker services (Queue processors, chron jobs).
- Lightweight gRPC microservices.
- CLI Tools.
Do NOT use Native AOT for:
- Large ASP.NET Core MVC / Razor Page apps.
- Apps heavily dependent on EF Core or Reflection.
- Apps that dynamically load plugins or assemblies at runtime.
The Verdict
Native AOT proves that C# can compete toe-to-toe with Go and Rust in the cloud-native, serverless space. Just be prepared to change how you write code. It forces you to be explicit and static—which, honestly, is probably how we should have been writing our high-performance APIs all along.