I’m running into this annoying pattern with LangChain agents over relational data.
The data already lives in Postgres, but the questions the agent needs to answer are rarely simple “select X where Y” queries. They’re usually multi-hop queries.
But doing this directly in Postgres gets ugly fast. I keep ending up with a pile of joins, recursive CTEs, hardcoded traversal logic in the app, or a bunch of very specific tools like get_customer_tickets, get_ticket_comments, get_invoice_owner, etc.
The agent also gets confused sometimes. Sometimes it needs to explore the relationships dynamically, which is where SQL starts feeling like the wrong abstraction.
The obvious answer is “use a graph database,” but that feels heavy too. Now you’re syncing data into Neo4j or something similar, learning Cypher, duplicating permissions, and keeping another database consistent with Postgres.
So I’m curious how people are actually solving this in production.
Are you giving agents a bunch of narrow SQL tools? Letting them write SQL directly? Using recursive queries? Syncing to a graph DB? Building an internal graph layer? Or just avoiding this kind of multi-hop traversal altogether?
The thing I want is basically graph traversal over existing Postgres data without moving the whole dataset into a separate graph database.