Back to browse
TypeGraph – Type-safe graphs on Postgres/SQLite (no graph DB required)

TypeGraph – Type-safe graphs on Postgres/SQLite (no graph DB required)

by pdlug·Feb 24, 2026·5 points·0 comments

AI Analysis

●●●BangerSolve My ProblemBig BrainShip It

Graph semantics on Postgres without Neo4j infra overhead or hand-rolled boilerplate.

Strengths
  • Zod as single source of truth drives schema, validation, and TS types simultaneously
  • Fluent traversal builder is fully typed and catches multi-hop errors pre-execution
  • Adapter abstraction scales seamlessly from SQLite to Postgres clusters
Weaknesses
  • Graph database operators (Neo4j, ArangoDB) already mature and optimized for complex traversals
  • Developer adoption depends on Zod ecosystem mindshare in knowledge graph space
Target Audience

Developers building RAG systems, permissions models, recommendations, and knowledge graphs

Similar To

Neo4j · ArangoDB · TigerGraph

Post Description

Hi HN, I built TypeGraph, a type-safe knowledge graph library that runs on your existing Postgres or SQLite.

After years of building knowledge graphs and other graphy things, I had the same issues whenever an application’s relationship modeling (permissions, RAG context, recommendations) outgrew standard ORMs: deploy a dedicated graph database (heavy ops, separate infra, data syncing headaches), or roll a graph-in-SQL implementation by hand.

I've hand-rolled enough of these to know the drill: same table structures, same traversal boilerplate, same performance surprises. I wanted graph semantics without graph infrastructure so I built TypeGraph as that pattern packaged as a library. It runs on anything from in-memory SQLite to a full Postgres cluster, using Zod for a single source of truth (driving your DB schema, API validation, and TS types).

You query it with a fluent builder that's fully typed through traversals:

const results = await store .query() .from("Person", "p") .traverse("worksAt", "e") .to("Company", "c") .whereNode("c", (c) => c.industry.eq("Tech")) .select((ctx) => ({ person: ctx.p.name, company: ctx.c.name, role: ctx.e.role, })) .execute();

Eject at any time and you're left with clean, well-structured SQL tables and nothing proprietary to untangle.

A few things that set it apart from rolling your own:

* Ontology reasoning: subClassOf, implies, inverseOf — query for "Media" and automatically get Podcasts and Articles. Define "Admin implies Editor" and permission checks expand automatically.

* Vector + graph queries: combine embedding similarity search with graph traversal in one query. Uses pgvector on Postgres, sqlite-vec on SQLite.

* Incremental adoption: builds on Drizzle. Add graph capabilities to an existing project without replacing your ORM or migrating your database.

Where it works well: knowledge graphs for RAG (vector similarity + graph context), relationship-based access control, recommendations, social features, any domain where multi-hop relationships are core.

Where it doesn't: billions of edges (use a graph database), heavy graph algorithms like PageRank (use specialized tools), distributed graph processing.

Docs: https://typegraph.dev

GitHub: https://github.com/nicia-ai/typegraph/

Happy to answer questions about the design, implementation, or tradeoffs.

Similar Projects