> JIT warmup is real. The first call to any method pays the compilation cost. In a database engine, the first transaction after startup shouldn’t be 100x slower than the steady state.

Correct me if I'm wrong but isn't it what aot was supposed to solve?

Also worth mentioning are VeloxDB and RavenDB, both written in C#. TBF, I haven't used any of them... but aware they exist.

C# is pretty powerful and capable of lower level usage, such as in the examples given... not to mention a pretty nice interop with C-style libraries. It looks like the intent here might be a custom database engine for service integrations... not necessarily a full rdbms in and of itself.

I would be less worried about the GC pause, than the need to reserve some memory for garbage collection. Any reduction in available memory is going to tend to mean a hit to performance.

That seems great, I have seen a few similar dbs written in java that say the same thing, that when written correctly you can get the perf very close to C, but at that point you are just writing C with a different syntax. You don't win on any in the security guarantees, so at that point can we just not build everything in wasm and then we can interface it from both dotnet and the jvm?

I wonder why he didn't use AOT compiling if he's worried about JIT warmup.

C# is a great language with almost unlimited power and great ergonomics (as the article shows), but the .NET CLR (runtime) is a bit overcomplicated with a distinct "Java smell", and packaging and distribution is still meh.

If they could make the developer experience similar to Go, it would rule the world...