Announcing hgres

Following yesterday’s announcement of SemType, today we’re releasing hgres — the graph data engine that has been powering HASH since 2021 — as a standalone “layer” that can be headlessly run on its own.

Why hgres

A semantically typed world needs SemType infrastructure to run on. Most existing graph and relational databases were designed long before a portable, semantic type system existed, and treat type information as something the application layer should worry about — best-effort, untyped at the wire, and re-validated every time data crosses a boundary.

hgres takes the opposite stance: types are part of the storage layer, part of the query layer, and part of the transport layer. Constraints are enforced where the data lives, queries are typed programs the compiler can reason about, and protocols carry version and shape information end-to-end... evaporating the line between the database, queries, and the API.

What it is

hgres is composed of three open-source layers that work together, but can also be adopted independently:

• hGraph is the storage layer — a typed, multi-temporal knowledge graph that implements SemType’s data model directly and tracks every change across two independent time axes (transaction time and decision time). Prior state is always recoverable, never overwritten.
• HashQL is the query and execution layer. Instead of typing only data, HashQL types queries — bringing the same type safety that exists in the application layer to data access. Aggregations, transformations, and filters are part of the same typed program. The compiler determines which storage backend handles each part of a query and runs placement algorithms to colocate data and computation, so time-series data can live in a time-series store while still being part of the same query.
• HaRPC is the transport layer — a typed, semantically-versioned, stream-based RPC framework. Subsystems and procedures are versioned, breaking changes are first-class, and the client stays minimal and portable so the same straightforward implementation works in any language that can open a connection.

Each layer extends the same discipline — typed, versioned, and semantically meaningful — into a different slice of the stack.

A “layer” of HASH, now headless

hgres has been the data engine inside HASH for more than five years. Every production knowledge graph, structured-data pipeline, and agent workflow our users have built has, underneath, been backed by some version of these three components — running quietly as a single internal subsystem of the wider HASH application.

With today’s release, that subsystem is no longer just a HASH internal. The three layers can be deployed and operated independently — headlessly, on their own terms, without the rest of HASH. HASH itself sits on top, adding entity editing, type editing, ontology and knowledge graph management, data integrations, dashboarding, data analytics, and agentic orchestration. Adopt the data engine on its own, or take HASH as a fully-integrated platform — either path is a supported one.

Why we’re releasing it

A few reasons.

First, standards need reference implementations. SemType is positioned as an open standard, but a standard without an open, working implementation isn’t really one. Releasing hgres gives SemType a reference implementation that lives independently of the full HASH application — one that other projects can adopt, fork, learn from, or even compete with — and that makes the standard’s commitments concrete in code.

Second, the timing is right. The five years hgres has spent inside HASH coincided neatly with the rise of LLMs, and with the broader realization across our industry that AI agents and applications need typed, semantically-meaningful infrastructure — not just vector indexes bolted onto schemaless stores. We’ve been asked, with increasing frequency, whether the engine running underneath HASH was available on its own. The answer is now yes.

Third, openness compounds. We’ve always been an open-source company, and we don’t think a piece of generally-useful data infrastructure should sit locked inside a single product. A wider community of users hardens the layers, finds edges we’ve missed, and builds things on top of hgres that we wouldn’t have thought of ourselves — work that, in turn, we’ll often want to use back inside HASH.

Where to find it

The full architecture, layer-by-layer documentation, and getting-started guides live at hgres.org:

• Architecture overview — how the three layers fit together.
• hGraph, HashQL, and HaRPC — each layer in detail.
• Source on GitHub — hgres is part of the broader HASH monorepo.

Get involved

hgres is open source and welcomes contributions. Try it out, build something on top of one or all of its layers, and tell us what breaks: hey@hash.ai, or open an issue or discussion in the HASH repository.