What is ConvergeDB?

ConvergeDB is a database purpose-built for one job: giving every service in a game’s infrastructure a unified, real-time view of state that is spread across multiple game servers.

Each game server (a source) continuously asserts the current state of the entities it owns. ConvergeDB merges these assertions into a single converged view and pushes change notifications to any service that subscribes. Matchmakers, dashboards, analytics pipelines, and anti-cheat services all connect to ConvergeDB instead of reaching into individual game servers.

The problem

In a multi-server game, each server owns a slice of the world. The rest of the infrastructure needs to see all of it. Typically this means building a bespoke integration layer: pub/sub, a shared cache, merge logic to reconcile writes from different servers, and cleanup jobs to remove state from servers that crashed.

That ad hoc layer grows with every new consumer. Each one re-implements bootstrapping (getting the current world state on startup), handles reconnection differently, and makes its own assumptions about ordering. The merge logic is subtle, the failure modes are silent, and it’s never anyone’s job to own it.

ConvergeDB replaces that layer with a database designed around the problem from the start.

What you get

Multiple servers write independently, the database maintains the merged view

Every game server is a source with its own identity (0 to 63). When two servers assert the same entity, ConvergeDB tracks their contributions independently using per-entity source bitsets. There is no conflict resolution because there are no conflicts: assertions from different sources are merged, not arbitrated.

A server dies, its entities are cleaned up automatically

ConvergeDB tracks liveness per source. When a game server disconnects or crashes, the server stops receiving heartbeats. After the liveness deadline (default: 30 seconds), every entity that only that source asserted is tombstoned and subscribers are notified. No orphan state, no cleanup jobs.

High-frequency writes become bounded-rate notifications

Game servers may update entity positions at 60Hz or higher. ConvergeDB coalesces writes within a configurable window (default: 20ms), so downstream services receive approximately 50 updates per second per entity instead of thousands. The database absorbs the write amplification so your infrastructure does not have to.

New services get the full world state, then live deltas, with no gaps

When a service subscribes with bootstrap enabled, ConvergeDB sends a complete snapshot of all existing entities, then transitions seamlessly to live change notifications. There is no window where the subscriber has partial state, and no need to stitch together a query and a subscription yourself.

Current state only, point reads in microseconds

ConvergeDB stores exactly one version of each entity. There is no history, no growing WAL for readers, and no cold storage tier. Point reads are a single hash lookup served entirely from memory. This simplicity is what makes the rest possible: coalescing works because the database does not preserve every write, and bootstrap works because the full state is always in memory.

How it works

1. Sources assert state. Each game server declares the full current state of the entities it knows about. There is no insert/update distinction. If the entity exists, its state is updated. If it does not exist, it is created.

2. The database converges. When multiple sources assert the same entity, ConvergeDB merges their contributions using source-level tracking. Each source’s latest assertion wins for the fields it owns.

3. Subscribers see changes. Any service can subscribe to an entity kind and receive a real-time stream of create, update, and delete notifications with field-level change tracking.

What ConvergeDB is not

ConvergeDB is deliberately narrow in scope. Understanding what it does not do is just as important as understanding what it does.

• Not a relational database. There is no SQL, no joins, no foreign keys, and no transactions. Each entity kind is an independent flat collection.
• Not a message queue. There are no delivery guarantees on historical messages, no consumer groups, and no replay. Subscribers see current state and live changes only.
• Not a document store. Schemas are fixed at registration time with typed fields. Entities are flat with one level of struct nesting.
• Not an event log. ConvergeDB stores only the current state of each entity. There is no history, no temporal queries, and no event sourcing.

Out of scope for v1

The following features are explicitly deferred:

• Multi-node clustering and replication
• Field-level subscription filtering
• Secondary indexes and predicate-based queries
• Authentication and encryption (TLS)
• Transaction support (multi-entity atomic operations)
• Historical state queries