How we think about the graph

We get this question from technical evaluators every week. Why Postgres and not a graph database? The honest answer is that Postgres in 2026 is a remarkably capable foundation for typed graph storage, and the operational benefits of a single proven primary store are enormous.

We use ltree for hierarchies, citext for case-insensitive identifiers, pgvector for embedding columns, and a small handful of recursive CTEs for graph traversal. The schema is typed and constrained — entities have types, edges have semantics — and the queries we care about are usually three or four hops, not the deep traversals where dedicated graph databases shine.

The trade is real. Some workloads — fraud rings, social graph cycle detection — really do benefit from a native graph engine. The workloads we care about — 'who owns this workflow, what does it depend on, who has been near it recently' — are bounded, indexable, and well served by relational primitives. We get RLS, transactional integrity, point-in-time recovery, and one operational story for the price of one database. The simplicity is a feature.