hgDB
A Rust database that brings PostgreSQL-compatible SQL, search, vectors, graph, geospatial data, key-value access and workflows onto one storage layer.
The problem worth solving
Modern applications routinely copy the same data into a relational database, search engine, vector store, graph system and workflow service. Every copy adds synchronization logic, operational overhead and another place for the truth to diverge.
What I built
hgDB explores a different architecture: specialized engines share one storage layer and remain accessible through a PostgreSQL-compatible wire protocol. SQL is the familiar front door, while search, vectors, graph, geospatial, key-value and workflow primitives operate inside the same system.
Those engines are indexes over shared data rather than independent systems of record. The design allows one transaction to work across several models without requiring the application to maintain duplicate copies or reconcile them after a partial failure.
What the product does
- PostgreSQL wire compatibility for existing database clients and application tooling.
- Relational, transactional JSONB and key-value access over a unified storage model.
- Full-text, vector and hybrid retrieval without a separate search service.
- Graph, geospatial and code-structure queries against the same underlying data.
- Durable workflows, queues and content-addressed artifacts within the database boundary.
Why the design matters
hgDB treats storage, retrieval, transactionality and developer experience as one product problem. It is systems work aimed at reducing the number of moving parts an application team must understand and operate before it can deliver value.
My role
Ciprian conceived hgDB, set its product model and architecture, and remains hands-on in its Rust implementation and public development direction.