Graph Queries In Postgres 19 Reach Production Only When Every Extension Version Aligns

Postgres is emerging as a single data layer for AI agents, holding transactional records, vector embeddings, and graph relationships in one system. Version 19, now in beta and due for general release in the fall, adds graph pattern matching to the database core, letting teams query relational tables as property graphs without a separate graph system. Whether that setup is ready for production depends on extensions. Vector search and graph traversal still arrive through community projects like pgvector, and those projects move on their own schedules after each Postgres release. Teams that depend on them wait.

Vladislav Galibov is Co-Founder of Croco.Team, a Portugal-based studio that builds and runs its own products. One of them, DocsMint, is a GraphRAG knowledge base built entirely on Postgres, with extensions handling the vector search and the graph traversal and no dedicated graph database anywhere in the stack. Galibov came to AI product development after more than 15 years building across tech, manufacturing, and digital products. DocsMint ships as a hosted service and as an open source install.

"You need one place for people's knowledge and for agents' knowledge, and you need to find it easily," says Galibov. Software vendors are building agents into the applications companies already run, and the share of apps with one inside is climbing fast. A single lookup by one of them often needs a stored document, a similar passage found by meaning, and the link between the two. Splitting those across separate databases means three systems to query and three copies to keep current. Keeping them together turns the same lookup into one query.

Skipping the graph database

Standard GraphRAG guidance says that graph work calls for a graph database. Galibov uses Postgres extensions instead, pairing pgvector for embeddings with Apache AGE for traversal. A dedicated engine would sit outside the main store and reach into it on every request, which slows answers down and leaves a copy that can drift. It is also one more service to install, upgrade and repair. "If you are looking for information, you should find one true answer," he says.

Enterprise architects have been making the same call, treating Postgres as the default database for AI workloads. Galibov recommends the approach to most builders. The exception is a product that needs very fast search across a very large set of embeddings, where a specialist tool still earns its place. Teams working from SQLite end up bolting extra services onto a database they picked for being simple.

Once a knowledge base holds a large number of documents, graph search built on extensions returns worse matches than a dedicated engine would, and people using the open source version have written to him about it. Splitting the graph layer into its own database is still on the table. He wants to test whether the graph support arriving in version 19 changes that. "It is too early to say whether this is the correct path," he adds.

Retrieval gets expensive

Every GraphRAG search calls an AI model as part of the lookup, and that step costs time and money on each request. With a handful of documents, nobody notices. "If you have synchronized 1,000 documents, it becomes a problem without big infrastructure," Galibov says. A small team that chose Postgres to avoid four services ends up paying for a bigger machine anyway. Agents sharpen that, since one task can trigger a dozen lookups and each costs the same as the last. Serving AI keeps turning into a storage problem.

Extensions are why Postgres can do any of this. Outside contributors built vector search and graph traversal as add-ons, and anyone could fill a gap the database had. "Postgres connects to many other products, it is easy to use, and you can build plugins for it," Galibov notes.

The same imbalance shows up in the agent market. Anyone can build an agent now, and the tools for it look much alike, while the storage and plumbing underneath take longer to build and cost more to keep running. The infrastructure layer trails the one above it. Version 19 narrows that gap for graph work. The feature is called SQL/PGQ, it comes with the core release, and it reads existing tables directly, so no data has to move and nothing extra has to be installed. Nothing else has to catch up first.

Everything on one version

Galibov called SQL/PGQ the change that matters most for GraphRAG systems when the beta arrived. He is still on an earlier release. Every part of his stack has to sit on the same version, and the extensions he depends on have not moved yet. "I cannot use it in my program because there are no plugins for 19," he says.

Shipping open source spreads that to everyone who installs it. Each person assembles the same set of extensions on their own machine, and a version that does not line up lands as a report in Galibov's inbox. The Postgres release, each extension on top of it, and the container images that package them all have to match. An upgrade that looks routine on paper stops on one piece that is not ready. This is part of what commercial and managed Postgres distributions do for customers, testing the combinations in advance and shipping a set that already works together. "You have to choose the right version of every part of the system, and that version race is one of the biggest problems," he warns.

Galibov thinks agents will eventually do this checking themselves, and he has started building in that direction. He has packaged 13 tools using Agent Plugins, an open format that lets an agent skill work the same way in any client, without a rebuild for each one. One of those tools connects to a Postgres database and reports back on query performance, locks and overall health. Another checks the packages for version conflicts before they go out, the same check a team performs by hand every time Postgres releases. All of it is early work, and it sits alongside other efforts to give agents common standards to work from. "When agents understand how all of these plugins and systems work together, they can connect them without engineers," he says.