Key takeaways from the PostgreSQL & AI Summit: RAG, agents, and tuning

I recently co-organized and co-hosted the inaugural PostgreSQL & AI Summit, as part of Community Events Day at PostgreSQL Conference Europe, alongside Gülçin Yıldırım Jelínek of xata and Torsten Steinbach of EDB. In this half-day event dedicated to exploring the intersection of PostgreSQL and AI, designed for DBAs, developers, engineers, data scientists, and AI enthusiasts building the next generation of intelligent applications, experts discussed how the world's most advanced open-source relational database is becoming the epicenter of the AI revolution.

Find out more here, including the speaker decks.

The tracks

The day was structured around two parallel tracks, ensuring attendees gained a comprehensive and multi-faceted understanding of the technology landscape:

Track 1: Vector & RAG

This track focused on leveraging PostgreSQL as a powerful backend for AI applications. Sessions dove deep into vector embeddings, semantic and hybrid search, vector search extensions like pgvector, and the architectures for building sophisticated Retrieval-Augmented Generation (RAG) and intelligent search systems.

Track 2: AI & tools

This track centered on using AI and ML applications to enhance and manage PostgreSQL itself. It covered building AI-powered agents to interact with PostgreSQL data, operating the database more effectively, ML-driven performance tuning, and the innovative tools that make running a smarter, more efficient database a reality.

Speaker session summaries

Here is a look at the key insights shared by our expert speakers:

Marc Linster, DBtune
AI for Postgres? Postgres with AI? Postgres for AI?

Marc kicked off the summit by defining the three core relationships between the technologies: AI for Postgres (making the database smarter with ML/AI-driven tuning), Postgres with AI (integrating native AI features like Approximate Nearest Neighbor indexing), and Postgres for AI (serving as the secure, enterprise-ready data repository for RAG context). Read his blog post to learn more.

Bruce Momjian, EDB
Databases in the AI trenches

Bruce explored the foundations of modern AI in the context of databases, detailing core concepts such as hyper-dimensional vectors, semantic search, Generative AI, and the critical role of RAG in connecting Large Language Models to PostgreSQL.

Torsten Steinbach, EDB
RaBitQ & GPU acceleration for high scale vector search with PG

Torsten focused on solutions for achieving high-scale vector search within PostgreSQL, specifically by leveraging the RaBitQ extension and GPU acceleration to handle the performance demands of massive vector datasets for RAG systems.

Gulcin Yildirim Jelinek, Xata
From DBA to DB agents

Gulcin charted the evolution of the database role, detailing the shift from the traditional DBA to the new paradigm of autonomous DB Agents. The talk highlighted how AI can automate complex DBA tasks and discussed the challenges of trust and safety in this transition.

Miguel Toscano, Google
Postgres + MCP: Better together

Miguel presented the Model Context Protocol (MCP) as the necessary standardization layer to securely and scalably integrate various AI Agents with PostgreSQL. This approach aims to solve the "Integration Maze" of bespoke API wrappers, ensuring reliable state changes and transactional integrity.

Luigi Nardi, DBtune
Workload Fingerprint: A data cleaning pipeline for effective AI performance tuning

Luigi introduced the concept of Workload Fingerprint as a crucial data cleaning pipeline to create robust input signals for AI-assisted performance tuning. He emphasized that the quality of AI/ML output is directly determined by clean, reliable performance metric input data, countering the "garbage in, garbage out" problem.

Bertrand Hartwig-Peillon, Hôpitaux Universitaires de Genève
pgAssistant

Bertrand demonstrated pgAssistant, an open-source, AI-powered tool designed to empower developers. It can detect, explain, and suggest improvements for SQL query optimization and schema design without requiring immediate involvement from a Database Administrator.

Daniel Krefl, Sendai
GPUs and Postgres: The Good, the Bad, and the Ugly

Daniel provided an in-depth, realistic look at using GPUs with PostgreSQL, covering the challenges of data transfer bottlenecks and the massive potential for compute-heavy operations. He concluded that the largest immediate potential for GPUs in Postgres is for accelerating AI inference via user-defined functions.

Adrien Obernesser, dbi services
Accelerating BI data marts building with pgvector

Adrien demonstrated a practical use case by detailing how to use a RAG agent and pgvector to accelerate BI data marts construction. The solution involves building a PostgreSQL metadata index on columns and business terms, allowing the RAG agent to retrieve relevant fields.

Jimmy Angelakos, pgEdge RAGtime with Postgres: AI Power with pgvector and Retrieval-Augmented Generation

Jimmy explored the practical implementation of RAG architecture using PostgreSQL. The talk demonstrated how to combine the power of AI with the reliability of pgvector to provide accurate, grounded answers from proprietary data.

Mohsin Ejaz, DBtune
How to let AI tune your database without breaking everything

Mohsin focused on the delicate but powerful topic of AI-driven database tuning. The session provided practical guidelines and safe strategies to let AI autonomously optimize database parameters and queries without introducing instability or "breaking everything."

Gleb Otochkin, Google
Vector data in Postgres: Size, TOAST, Filters and Performance

Gleb discussed the technical details of managing vector data in Postgres, covering concepts like vector embedding. Distance metrics (Euclidean, Cosine), index strategies (IVFFlat, HNSW), the impact of TOAST storage, and techniques for efficiently combining vector search with traditional filters.

Erik Hellsten, DBtune
Which parameters actually matter? A Machine Learning framework for server parameter importance analysis

Erik presented a machine learning framework for performing Feature Importance Analysis on PostgreSQL server parameters (like shared_buffers or max_parallel_workers). The goal is to use models like Random Forests to objectively determine which configuration settings have the highest correlation with target metrics like query latency or throughput.

Expert panel discussion

The afternoon culminated in a combined expert panel discussion where leaders from both the Vector & RAG and AI & Tools tracks debated the future of the field. Panelists include Torsten Steinbach, Gulcin Yildirim Jelinek, Mayuresh B, Luigi Nardi, Adrien Obernesser, Miguel Toscano and Bruce Momjian.

The panel provided a candid assessment of how the AI era is testing the very foundations of PostgreSQL's architecture. A major theme was the pressure for a single data source capable of handling traditional relational data, data warehouse workloads, and new, demanding vector search needs. Panelists, including Bruce Momjian, noted that this pressure is forcing the community to confront existing architectural limits, specifically around the overhead of storing and processing long vector embeddings and the challenges of integrating GPU acceleration. They stressed that while new index types like HNSW are exciting, the core engineering challenge is making them truly enterprise-ready—meaning fully ACID compliant, reliable, and integrated into the ecosystem's maintenance routines without compromising the stability and transactional integrity PostgreSQL is known for.

The discussion then pivoted to the operational revolution driven by AI, specifically the shift from Retrieval-Augmented Generation (RAG) to autonomous database agents. The critical challenge for the future is moving beyond AI that simply "knows" things to AI that can "do" things, such as executing complex SQL or optimizing performance. Panelists, including Gulcin Yildirim Jelinek and Luigi Nardi, unanimously emphasized that the success of DB agents hinges on establishing trust and sandboxing. Integrating AI into core deterministic components like the query planner must be handled with extreme caution to avoid introducing non-determinism, as hallucinations are mathematically inevitable in LLMs. Luigi Nardi also reinforced the consensus that safe, autonomous operation demands a core focus on input quality, which strongly validates the need for methodologies, such as the Workload Fingerprint method, to preserve the core reliability and explainable behavior that defines PostgreSQL.

This discussion strongly validated that safe AI operation requires robust guardrails and a focus on input quality, such as utilizing DBtune’s Workload Fingerprint method, to preserve the core reliability and explainable behavior that defines PostgreSQL.

Thank you to all our speakers, attendees, and organizers for making the PostgreSQL & AI Summit a success! We look forward to seeing the incredible autonomous applications and tooling that emerge from this community.

Stop guessing and start optimizing: Try DBtune for safe, AI-powered PostgreSQL performance tuning today.

Frequently asked questions

Q1: What is the single biggest architectural challenge PostgreSQL faces in the AI era?

The main challenge is the demand for PostgreSQL to be a unified data source—handling transactional (OLTP), analytical (OLAP/data warehouse), and new vector-based workloads all at once. Panelists noted this is straining the core architecture, particularly regarding the overhead of storing and processing long vector embeddings (e.g., using TOAST) and the engineering complexity of integrating high-performance features like HNSW indexes into the fully transactional, ACID-compliant core.

Q2: What is a "DB agent," and how is it different from RAG?

RAG (Retrieval-Augmented Generation) is AI that primarily "knows" things. It queries a database (like PostgreSQL with pgvector) to find relevant context and uses that context to generate a truthful answer.

A DB agent is AI that "does" things. It is autonomous and can execute actions against the database, such as writing complex SQL queries, optimizing schemas, or even changing server configuration parameters. The shift from RAG to DB agents is the transition from AI providing knowledge to AI performing actions.

Q3: Why did the panel stress the need for "guardrails" for AI?

The panel, including Gulcin Yildirim Jelinek and Bruce Momjian, stressed that for AI to be used in operations (DB agents), trust is non-negotiable. As Momjian noted, Large Language Models (LLMs) are non-deterministic systems whose operation is based on statistical prediction—meaning they are always generating a probable, rather than factual, response, even when the answer is correct. Because of this inherent risk, robust guardrails, auditing, and sandboxing are critical to prevent an AI from executing destructive SQL or making non-reversible, breaking configuration changes to a live production database.

Q4: Is using GPUs with PostgreSQL a viable option right now?

Yes, but in a very specific way. Daniel Krefl's talk confirmed that while tempting, the high I/O cost of moving large amounts of data between the CPU/RAM and the GPU means GPUs are generally not efficient for core database operations like sorting or joins. The largest immediate potential is for accelerating specific compute-heavy tasks like AI inference (e.g., running a model to generate embeddings or classify data) using user-defined functions entirely within the database.

Q5: How important is data quality for AI-assisted database tuning?

It is absolutely paramount. As Luigi Nardi and Erik Hellsten explained, AI-assisted tuning systems are subject to the "garbage in, garbage out" (GIGO) principle. Traditional performance metrics like average query runtime are too noisy due to factors like cache effects and multi-tenancy. To achieve reliable and explainable tuning, the process requires two distinct steps:

1. Data cleaning: The input performance data must first be cleaned and standardized using methods like Workload Fingerprint (as presented by Luigi Nardi).
2. Learning relevance: Then, techniques like Feature Importance Analysis are applied to this clean data to objectively determine which server parameters actually matter the most for performance (as presented by Erik Hellsten).

Without clean, standardized data, AI would be less capable of accurately learning the relationships and will make poor, potentially destructive decisions.