🐍 Typhon 🐍

GitHub, Documentation.

Overview: A High-Performance Component-Based Database for Game Development

Typhon Engine is a specialized database engine that combines the performance of an in-memory database with the reliability of persistent storage. It’s designed specifically for game development scenarios that require high-throughput data operations with transactional safety.

Core Features

Component-Based Architecture

Typhon uses a component-based architecture where data is organized into typed components rather than traditional tables. This approach aligns perfectly with Entity Component System (ECS) patterns commonly used in game development.

[Component(SchemaName)]
[StructLayout(LayoutKind.Sequential)]
public struct PlayerPosition
{
    public const string SchemaName = "Game.Components.PlayerPosition";
    public float X;
    public float Y;
    public float Z;
}

Powerful Transaction System

All operations are performed through transactions, providing ACID guarantees even in high-throughput scenarios:

• Create and read components within the same transaction or across different ones
• Update and delete with transactional safety
• Rollback support to handle errors or rejected changes
• Transaction isolation to prevent data corruption

Concurrency Control Options

Choose the concurrency model that fits your needs:

• Exclusive mode for critical operations that need to lock resources
• Optimistic concurrency for higher throughput when conflicts are rare

High-Performance Memory Management

The engine is built with performance as a top priority:

• Memory-mapped files for efficient data persistence
• Chunked storage system for optimal memory usage
• Advanced page caching to minimize disk I/O
• Optimized memory access patterns using unsafe code where needed

Indexing Support

Automatically create and maintain indexes for faster lookups:

[Component(SchemaName)]
public struct Enemy
{
    [Index(AllowMultiple = true)]  // Support multiple enemies at same position
    public float PositionX;
    
    [Index]  // Only one enemy per ID
    public int EnemyId;
}

Memory-Efficient Storage

The storage layer is designed to minimize memory overhead:

• Fixed-size chunks for predictable memory allocation
• Efficient bitmap tracking of allocated/free chunks
• Pooled accessors to reduce GC pressure

Use Cases

Typhon Engine is particularly well-suited for:

• Game state persistence with minimal performance impact
• High-frequency data updates common in simulation games
• Complex game worlds with many interrelated entities
• Networked games requiring transaction safety

The database engine provides a robust foundation for building complex, data-driven game systems while maintaining the performance needed for smooth gameplay.

Technical Foundation

Built on modern C# with careful optimization, Typhon Engine takes advantage of:

• Low-level memory operations for performance
• Thread safety for multi-core utilization
• Modern .NET features for developer ergonomics
• Dependency injection for flexible configuration

This combination delivers both the raw performance needed for games and the developer-friendly API needed for rapid development.

Why ?

Initially I wanted to “make a database engine for MMOs, something fast, reliable and scalable” (in that order).

Something like a weird mixed between ECS and a “regular database engine”.

Fast

In the realm of the micro-second. Concessions would have to be made, but it has to be fast, otherwise there’s no really a point to it.

More suitable

Not the original intent, but quickly a very interesting angle. Adopting some of the ECS principals would make this more natural for the users.

Reliable, meaning Durable (or not…)

Atomic, transaction-based and durable operations.

Through a design decision, the user can opt-out durability on chosen components.

Scalable

While it’s still a goal, the ambitions were tuned down. A theoretical evolution would be a shard/hash based implementation, but the resulting complexity makes this no longer an objective.

History

This project went through many things:

• Bootstrapped in 2015 with a very different design and intent, then quickly put on a shelf.
• Resurrected during COVID in 2020 as a POC of “is it possible to make a real-time ACID database, down to the µs”, oriented for persistent games ? Then put on a shelf after promising work.
• Many concepts around unsafe/GC-free .net programming lead me to develop 🍅, but the two projects are not dependent. I, for once, successfully restrained myself to retrofit 🍅 into this one, it’s totally doable, but as usual, just a matter of time…
• Re-resurrected in summer 2025 with the “firm, but fragile” intention to reach an alpha stage.