April 10, 2026
GC vs Go vibes: choose your fighter
Why I'm Building a Database Engine in C#
C# database dreams ignite: “Java smell,” AOT wars, and memory panic
TLDR: A developer is building a lightning-fast database in C#, arguing modern tools tame garbage collection and startup lag. The crowd is split: some slam .NET’s “Java smell” and demand AOT, others worry memory costs hurt speed—making this a high-stakes test of whether managed languages can go ultra-low latency.
A solo dev just dropped a bold claim: a tiny, embedded database in C# aiming for 1–2 microsecond commits, with full ACID safety (think bank-level “your data won’t vanish”) and game-engine vibes. He says modern C# sidesteps the scary stuff—garbage collector pauses, memory shuffling, and first-run slowdowns—using low-level tricks, pinned memory, and stack-only types. Ambitious? Absolutely. Uncontroversial? Not even close.
Comments lit up like a code fight club. The loudest chorus: “Cool idea, shame about the vibe.” One top voice said the .NET runtime still has a “Java smell,” roasting the packaging experience and wishing C# felt more like Go’s one-binary simplicity. Another camp yelled: just use AOT (ahead-of-time compile) if JIT warmup is the boogeyman—cue the meme: “AOT or riot.” Then the performance purists crashed in, claiming the real villain isn’t pauses but memory—reserving heap space for the garbage collector could kneecap speed. For credibility checks, someone name-dropped other C# databases (VeloxDB, RavenDB), which sparked the classic “Have you even used them?” clapback. Meanwhile, jokers sprayed Febreze on that “Java smell,” others chanted “GC stands for ‘Gasping CPU,’” and one optimist cheered that games + databases might actually get along. The vibe: wild hope meets spicy skepticism, with popcorn on standby and part two of the series bookmarked for drama.
Key Points
- •Typhon is an embedded, persistent ACID database engine written in .NET and aimed at 1–2 microsecond transaction commits.
- •Typhon targets game servers and real-time simulations and claims MVCC snapshot isolation, cache-line-aware storage, zero-copy access, and configurable durability.
- •The article enumerates common objections to C# for microsecond-latency engines: non-deterministic GC pauses, lack of memory layout control, JIT warmup, and runtime overhead from virtual dispatch and bounds checks.
- •It argues modern C# offers mitigations: unsafe code for C-like control, GCHandle pinning to prevent object movement, and ref struct types to avoid heap allocations on hot paths.
- •Typhon applies these features, including a pinned page cache and a ref-struct-based entity accessor (EntityRef), to meet strict latency targets.