Why I'm Building a Database Engine in C#

jaen

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...

tracker1

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.

benterix

> 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?

DeathArrow

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

nitwit005

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.

alex7o

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?

zerr

I'd say modern C++ is high level and ergonomic enough to stop considering any language with a GC.

achillesheels

You do you.

kerblang

Am amused that someone feels compelled to justify writing a db in C#. Such conscientiousness! I'm not sure authors of Cassandra, ElasticSearch, MongoDB (and more...?) ever had the slightest twinge of uncertainty about whether a managed memory env would cause far more problems than it fixed, even with less native tooling than in C#. Java bros DGAF

gwbas1c

Regarding tradeoffs: I've been working with C# for most of my career, almost 25 years, since .Net 1.0. One of the huge things that I love about Rust is the lack of a runtime framework. I don't need to figure out how to bundle / ship / install a framework at runtime. (I also like Cargo better than Nuget, but that's a very subjective opinion.) Which leads to probably the biggest tradeoff: > Typhon is an embedded... It's probably hard, (or impossible) to use Typhon outside of the dotnet ecosystem. Granted, it's been years (since the 1.0 days) since I built a .dll that a native application could pull in, there are complications when you "impose" dotnet into an application that isn't dotnet. These don't happen when your library is 100% native, which you get with C/C++/Rust.

InMemoryNet

We have a pretty fast InMemory Database for .Net as well, named InMemory.Net!

teleforce

>But what about GC pauses GC is like auto transmission, it's an inevitable natural evolution of programming languages. I think the future of programming languages will have hybrid modes of GC and manual, similar to today's hybrid auto transmission automatic and manual in state-of-the-art hypercar [1]. I considered D language as pioneer in this innovative approach. My hypothesis is that GC can be made deterministic like manual memory management, just like how ICE auto industry minimize the manual transmission. Heck, no manual for EV. Hopefully the new io_uring facility with BPF controlled can enable this deterministic GC [2],[3]. [1] Here’s how Koenigsegg’s new manual/automatic CC850 gearbox work (2025): https://www.topgear.com/car-news/supercars/heres-how-koenigs... [2] BPF meets io_uring (2026): https://lwn.net/Articles/847951/ [3] How io_uring and eBPF Will Revolutionize Programming in Linux (2020): https://www.scylladb.com/2020/05/05/how-io_uring-and-ebpf-wi...