u/pdlug

I'm a huge fan of graphs, they tend to simplify a lot of problems (permissions that inherit, content that relates, entities for RAG, etc.) and preserve optionality when the data modeling is uncertain. Most of the time you need a graph, you don't need a graph database. Your app already has a perfectly good SQL DB and you can get pretty far with recursive CTEs. After building this a few dozen times I decided to package it all up with a nice DX and open source it.

TypeGraph (open source, I'm the author) is a graph modeling + query layer that compiles to SQL. It is explicitly not a graph database — you keep your Postgres/SQLite, your transactions, your backups, and you inherit your DB's performance. Comes with some tradeoffs but also a lot of power, like being able to connect from relational to graph.

• Each algorithm (shortestPath, reachable, canReach, neighbors, degree) compiles to one recursive CTE with cycle detection and depth limits — identical semantics on SQLite and Postgres
• Postgres CTEs emit NOT MATERIALIZED hints; LIMIT is pushed past GROUP BY in safe aggregation cases
• Server-side prepared statements (named) cache plans — ~6× faster on multi-hop traversals in my benchmarks
• refreshStatistics() wraps ANALYZE (per-table on PG) for post-bulk-load plan stability
• withTransaction(externalTx) shares one transaction across TypeGraph and your existing Drizzle/relational writes — atomic across both models, no data syncing
• Multi-driver Postgres: node-postgres, postgres-js, Neon WS + HTTP; SQLite via better-sqlite3, libsql, and Cloudflare Durable Objects

Embraces TypeScript and related libraries: a single Zod schema per node/edge is the source of truth for runtime validation, storage, and type inference. Result types come from your select clause. Traversal autocomplete only shows valid target kinds.

It ships a basic ontology with the ontology as data so you can do things like admin.implies(editor) and every query expands automatically, no getEffectivePermissions() duplicated across services.

It does all the fancy AI stuff too (semantic search, fulltext, hybrid retrieval w/ RRF) but it's really just graphs done right on top of a DB you're probably already using

Honest feedback welcome, especially on the type ergonomics.

GitHub: https://github.com/nicia-ai/typegraph · Docs: https://typegraph.dev

I'm a huge fan of graphs, they tend to simplify a lot of problems (permissions that inherit, content that relates, entities for RAG, etc.) and preserve optionality when the data modeling is uncertain. Most of the time you need a graph, you don't need a graph database. Your app already has a perfectly good SQL DB and you can get pretty far with recursive CTEs. After building this a few dozen times I decided to package it all up with a nice DX and open source it.

TypeGraph (open source, I'm the author) is a graph modeling + query layer that compiles to SQL. It is explicitly not a graph database — you keep your Postgres/SQLite, your transactions, your backups, and you inherit your DB's performance. Comes with some tradeoffs but also a lot of power, like being able to connect from relational to graph.

• Each algorithm (shortestPath, reachable, canReach, neighbors, degree) compiles to one recursive CTE with cycle detection and depth limits — identical semantics on SQLite and Postgres
• Postgres CTEs emit NOT MATERIALIZED hints; LIMIT is pushed past GROUP BY in safe aggregation cases
• Server-side prepared statements (named) cache plans — ~6× faster on multi-hop traversals in my benchmarks
• refreshStatistics() wraps ANALYZE (per-table on PG) for post-bulk-load plan stability
• withTransaction(externalTx) shares one transaction across TypeGraph and your existing Drizzle/relational writes — atomic across both models, no data syncing
• Multi-driver Postgres: node-postgres, postgres-js, Neon WS + HTTP; SQLite via better-sqlite3, libsql, and Cloudflare Durable Objects

Embraces TypeScript and related libraries: a single Zod schema per node/edge is the source of truth for runtime validation, storage, and type inference. Result types come from your select clause. Traversal autocomplete only shows valid target kinds.

It ships a basic ontology with the ontology as data so you can do things like admin.implies(editor) and every query expands automatically, no getEffectivePermissions() duplicated across services.

It does all the fancy AI stuff too (semantic search, fulltext, hybrid retrieval w/ RRF) but it's really just graphs done right on top of a DB you're probably already using

Honest feedback welcome, especially on the type ergonomics.

GitHub: https://github.com/nicia-ai/typegraph · Docs: https://typegraph.dev