Brand & press kit

Memory above, PostgreSQL below.

HorizonDB: a Rust JSON key-value server over WebSocket. Memory above, PostgreSQL below.

HorizonDB is the key-value server behind iHorizon. Written in Rust, it answers every read and write from memory over a single WebSocket, then flushes your JSON documents to PostgreSQL in batches. Dot keys address inside documents, mutations return their result, and a zero-dependency TypeScript client for Bun speaks the protocol.

HorizonDB is a JSON key-value server written in Rust (edition 2024), built for the iHorizon Discord bot. A bot hammers a handful of large JSON documents from many shards at once: a SQL round trip on every write is too slow, and memory alone forgets on restart. HorizonDB sits on the line between the two. Every get, set, add and push is served from memory, behind a lock per document, and edits in place. Every few minutes a background task flushes the changed keys to plain PostgreSQL tables with batched UNNEST upserts; a graceful shutdown flushes everything first. Idle documents are packed about ten times smaller, and clean ones leave memory until they are needed again. Clients speak JSON over one WebSocket, with pipelined requests and answers that carry their result. A zero-dependency TypeScript client for Bun ships in the repository. The wire protocol may still change.

La mémoire au-dessus, PostgreSQL en dessous.

HorizonDB : clé-valeur JSON en Rust sur WebSocket. La mémoire au-dessus, PostgreSQL en dessous.

HorizonDB est le serveur clé-valeur qui fait tourner iHorizon. Écrit en Rust, il répond à chaque lecture et écriture depuis la mémoire, sur un seul WebSocket, puis verse vos documents JSON dans PostgreSQL par lots. Les clés pointées adressent l'intérieur des documents, les mutations renvoient leur résultat, et un client TypeScript pour Bun, sans dépendance, parle le protocole.

HorizonDB est un serveur clé-valeur JSON écrit en Rust (édition 2024), conçu pour le bot Discord iHorizon. Un bot martèle quelques gros documents JSON depuis de nombreux shards en même temps : un aller-retour SQL à chaque écriture est trop lent, et un stockage purement en mémoire oublie tout au redémarrage. HorizonDB se tient sur la ligne entre les deux. Chaque get, set, add et push est servi depuis la mémoire, derrière un verrou par document, et modifie sur place. Toutes les quelques minutes, une tâche de fond verse les clés modifiées dans de simples tables PostgreSQL, par upserts UNNEST groupés ; un arrêt propre vide tout d'abord. Les documents inactifs sont compactés environ dix fois plus petits, et les documents propres quittent la mémoire jusqu'à leur prochain usage. Les clients parlent JSON sur un seul WebSocket, avec des requêtes en pipeline et des réponses qui portent leur résultat. Un client TypeScript pour Bun, sans dépendance, est livré dans le dépôt. Le protocole peut encore évoluer.

## HorizonDB: memory above, PostgreSQL below

The key-value server behind iHorizon now has its own home.

- **Memory first**: every get, set, add and push answers from memory, edited in place
- **Write-behind**: changed keys are flushed to plain PostgreSQL tables in batches, and everything on a clean shutdown
- **One WebSocket, JSON in and out**: mutations return their result, no follow-up read
- **TypeScript client for Bun** with zero dependencies

Written in Rust. Still a work in progress: the protocol may change.

https://ihrz.gitlab.io/db/
Code: <https://gitlab.com/ihrz/db>

HorizonDB is a JSON key-value server written in Rust. Reads and writes answer from memory over one WebSocket, then settle into PostgreSQL in batched upserts. TypeScript client for Bun, zero dependencies.

Memory above, PostgreSQL below.
https://ihrz.gitlab.io/db/

HorizonDB: a JSON key-value server that keeps memory above and PostgreSQL below

A Discord bot hammers a few large JSON documents (a guild, a member, a counter) from many shards at once. A SQL round trip on every write makes that slow; a pure in-memory store forgets everything on restart. HorizonDB, the server behind the iHorizon bot, sits on the line between the two.

How it works:
- Every read and write is served from memory. A push into a multi-megabyte document edits it in place instead of copying it.
- Every flush_interval_secs (300 s by default), changed keys go down to plain PostgreSQL tables in batched UNNEST upserts. A graceful shutdown flushes everything first; a crash can lose up to one interval of writes, and you choose that interval.
- Read-modify-write is serialized per key: sixteen workers on one counter end on the exact sum, checked on every benchmark run.
- Idle documents are packed about ten times smaller in memory. In one measurement (release build, 200 000 documents of about 1 KB), resident memory after 80 s idle went from 2 703 MiB to 60 MiB with idle eviction, or 360 MiB with every document kept in memory.

It is written in Rust (2024 edition, unsafe forbidden), speaks JSON over a single WebSocket, and ships a zero-dependency TypeScript client for Bun. Still a work in progress: the wire protocol may change.

Landing page: https://ihrz.gitlab.io/db/
Code and design notes: https://gitlab.com/ihrz/db

## HorizonDB : la mémoire au-dessus, PostgreSQL en dessous

Le serveur clé-valeur qui fait tourner iHorizon a maintenant sa propre page.

- **La mémoire d'abord** : chaque get, set, add et push répond depuis la mémoire, modifié sur place
- **Write-behind** : les clés modifiées descendent par lots dans de simples tables PostgreSQL, et tout part à l'arrêt propre
- **Un seul WebSocket, du JSON** : les mutations renvoient leur résultat, sans relecture
- **Client TypeScript pour Bun**, sans dépendance

Écrit en Rust. Toujours en chantier : le protocole peut encore changer.

https://ihrz.gitlab.io/db/
Code : <https://gitlab.com/ihrz/db>

HorizonDB, serveur clé-valeur JSON en Rust. Lectures et écritures servies depuis la mémoire sur un seul WebSocket, puis versées dans PostgreSQL par lots. Client TypeScript pour Bun, zéro dépendance.

La mémoire au-dessus, PostgreSQL en dessous.
https://ihrz.gitlab.io/db/

HorizonDB : un serveur clé-valeur JSON, la mémoire au-dessus et PostgreSQL en dessous

Un bot Discord martèle quelques gros documents JSON (une guilde, un membre, un compteur) depuis de nombreux shards en même temps. Un aller-retour SQL à chaque écriture, c'est lent ; un stockage purement en mémoire oublie tout au redémarrage. HorizonDB, le serveur derrière le bot iHorizon, se tient sur la ligne entre les deux.

Comment ça marche :
- Chaque lecture et chaque écriture est servie depuis la mémoire. Un push dans un document de plusieurs mégaoctets le modifie sur place au lieu de le copier.
- Toutes les flush_interval_secs (300 s par défaut), les clés modifiées descendent dans de simples tables PostgreSQL, par upserts UNNEST groupés. Un arrêt propre vide tout d'abord ; un crash peut perdre jusqu'à un intervalle d'écritures, et c'est vous qui le réglez.
- Les lectures-modifications-écritures sont sérialisées par clé : seize workers sur un même compteur tombent pile sur la bonne somme, vérifié à chaque passe de benchmark.
- Les documents inactifs sont compactés environ dix fois plus petits en mémoire. Sur une mesure (build release, 200 000 documents d'environ 1 Ko), la mémoire résidente après 80 s d'inactivité est passée de 2 703 Mio à 60 Mio avec l'éviction, ou 360 Mio en gardant tous les documents en mémoire.

Il est écrit en Rust (édition 2024, unsafe interdit), parle JSON sur un seul WebSocket et fournit un client TypeScript pour Bun sans dépendance. Toujours en chantier : le protocole peut encore changer.

Page du projet : https://ihrz.gitlab.io/db/
Code et notes de conception : https://gitlab.com/ihrz/db