Trip Report: VLDB 2026

Think Links ·

11 min read Original article ↗

Just over a week ago, I was at the 52nd International Conference on Very Large Data Bases (VLDB 2026). The first VLDB was held roughly 50 years ago in Boston – well close to Boston in Framingham – so it felt appropriate to come back. In 1975 there were 100 attendees, this year there were over 1200.

The organisers celebrated this homecoming with a nice plenary session reflecting on how the community has developed over the years and lessons learned. It was really neat to hear luminaries in the field discuss this. It’s clear that even as the field has evolved core data managements topics have remained. Here are some lessons learned from Michael Stonebraker coming from the debate that was happening at the time about database schemas:

Personally, the first lesson learned resonates with me. At INDE lab, we believe that looking at what people actually do around data is an excellent way to doing data management and data science research. Something I didn’t know about VLDB, which I found out from the presentation in the session by Renée Miller, was the initial focus of VLDB on international diversity. From the beginning, the conference organization made a concerted effort to make sure that institutions outside the US were included in the conference including in the set of publications. She made a compelling case that exactly this sort of proactiveness in including people and organisations made the community much stronger.

So what was I doing there? We had a research track paper led by David with Hazar and myself: Fault Lines: Benchmarking the Impact of Label Data Quality on ML Robustness and Fairness. This was David’s first conference and he did a really good job of presenting, got some good connections, and I think had a good time. I maybe even convinced him that baseball is actually a fun sport ⚾️😀.

What I really enjoyed about the conference was that many of the problems I’m interested in were well represented: multimodality and unstructured data, human data interaction, semantics, and the intersection of AI and data management. Below are my three main themes coming from the conference:

Agentic Workloads

AI and the use of AI for data management was pervasive at the conference from the two conference key keynotes to pretty much every workshop invited talk where I was not to mention many many papers. It’s not just that the massive use coding agents to help with programming but really that software is being almost completely generated by AI. Tim Kraska summarised this as “Programming is dead. Engineering is alive.” On the even bolder end was the message I took from Benjamin Wagner from Firebolt Analytics keynote at the Composable Data Analytics Workshop – just don’t bother building core database algorithms agents can synthesize these better and compose databases from the ground up (See their CAIS paper.) Focus on building database factories not databases.

AI is changing how we build data management systems, but AI agents also use databases in completely different ways. This is something I’ve seen anecdotally in my use of AI, for example, Claude is very good at generating complex SQL queries to traverse datasets and is very handy with string operators. But what I found interesting is that we are starting to get more data on how agents use data management systems. In the keynote by Reynold Xin – chief architect and cofounder of Databricks, he discussed how agents tend to develop software in an evolutionary way with many many branches and hence create many many more databases during development and these databases have much shorter lifetimes (under 10 seconds). Here are statistics from neon.com a hosted Postgres database provider owned by Databricks along with what he summarised as agents needs from databases:

In Aditya Parameswaran‘s keynote at the Agentic Data Systems workshop, he showed statistics from Snowflake’s Cortex AI system that show the difference in the kinds of queries that agents make. First they issue lots of queries – some issuing over 1000+ queries in a session:

Second, the queries in these sessions are not simple. They can be expensive and expressive – scanning large amounts of data with text search (like I’ve seen) but also doing repeated joins and data profiling From his data, the median query consumed 400+ GB of data to produce just two rows. There were even sessions touching 470 TB of data. Similar to Xin’s argument, Aditya argued that we need data management primitives for agent workloads. In particular, primitives that enable agents to more easily probe databases and understand what’s in them and how they relate to the meaning of the questions posed by the users (see the next theme).

Supporting the evaluation of data systems for agents, I would point to the work on evaluation by Eugene Wu‘s team that I learned about at the conference. Namely, Branch Bench which evaluates branchable database systems on agentic tasks and Lake QA Bench which evaluates the ability for LLM agents to do complex reasoning tasks on data lakes where evidence support is needed. You can also see Wu’s slides from both the NOVAS/DashSys workshops here. I think there is a lot more work to do in defining good evaluation frameworks that particular take into account that workloads will change as people integrate agents into their workflows and processes.

The Imperative of Semantics

As someone who’s always thought that semantics was an underrated part of data management systems, it was nice to see that, with the emergence of agents, it’s now seen as fundamental. A good example, was Kraska’s new start-up coming out of MIT that is fundamentally based around defining an ontology (concretely a knowledge graph structure) to drive system development from the perspective of requirements and capabilities, not code (paper and video about some of the tech).

More concretely , I saw the focus on semantics from two well represented lines of work: Text-to-SQL and Semantic Query Processing (i.e. LLM operators in a SQL query). Both of these technologies have been rapidly deployed in production data management systems. For example, Snowflake, AWS Q and Tencent Cloud:

From the Text-to-SQL side, there were several papers that focused on improving or making the benchmarks better. I really liked the paper from Google Research: Developing and Benchmarking Verification Algorithms to Improve Text-to-SQL Generation by Tarfah Alrashed, Madhup Sukoon, David Karger and Natasha Noy. They argued for the importance of verification as part of these pipelines and found hundreds of errors in widely-used benchmarks. They also argued for the ability to abstain from answering by an agent as something that should be evaluated positively and not accessed negatively in benchmarks. Similarly, work by the team from UIUC documented inconsistent annotation in current benchmarks. Much of the difficulty here comes from the challenge of bridging the semantics of user’s intent expressed in natural language and the underlying data which may or may not have good enough metadata. This challenge is also discussed in Michael Stonebraker and Peter Baile Chen’s recent blog post for the CACM as well as their paper in the NOVAS workshop looking at enterprise Text to SQL on a real-world data coming from Intel. Also in this context, it’s vital to look at other dimensions than accuracy like cost. I really liked how Jalal Mahmud and Eser Kandogan from Megagon Labs depicted the challenges in semantics in their paper in these enterprise settings:

To start to address these gaps, Carsten Binnig’s team explored the use of knowledge graphs to help agents perform better in Text-to-SQL in enterprise settings.

In practice, the team from Turiso showed the importance of semantic knowledge in their application for analytics over credit union databases. Using tribal knowledge – or knowledge gained from experience – to correct Text2SQL seems very promising. The ParsEval demo showed an approach to trying to find where a query would breakdown by automatically generating counter example databases.

With respect to Semantic Query Processing, the focus of the papers I saw was really about going from showing that this can be done to optimising these queries. A big step forward is the SemBench benchmark, which has become the go-to-benchmark in measuring query performance for such systems. The benchmark was clearly a lot of work and credit to the team for putting the time and the resources into doing this. Also on the benchmark front was SemCEB from Andreas Kipf’s team which provides a new way to measure performance for cardinality estimation for semantic operators.

Systems implementing new optimizations for semantic queries include: Purdue’s iPDB built on top of DuckDB, Snowflake’s new Cortex AISQL engine, Cadenza that breaks down operators to improve optimization, Abacus a new cost based optimizer for Palimpzest, MOAR the new LLM based optimizer for DocETL, and Ken an execution engine for queries over unstructured data. Other interesting work I saw was prompt level batching and semantic join discovery.

I think MOAR illustrates one of the most challenging aspects of optimization in this space, the number of potential possible operators that an LLM can provide. See Table 2 on the number of rewrite directives in MOAR. The fundamental question is how one can effectively deal with this. In particular, as we potentially expand this approach out to full data science pipelines as discussed in the stratum vision paper by Sebastian Schelter and team. I thought Juliana Freire’s conclusion of her keynote at the DASHSys workshop summarised how semantics are crucial for building data systems tailored to agents:

Agentic memory as the next data management problem

The last theme coming out of the conference for me was the need for better systems to support agentic memory. Agents acquire knowledge from a large number of multimodal and heterogenous sources they also store them there (markdown files, code notes on random wikis). Wu argued that this means data management for agents is inherently concerned with data outside the DBMS. These considerations lead to the question that Friere posed “How do we build persistent, queryable, maintainable semantic knowledge that can be shared across models, algorithms, agents, and users?” Here I really appreciated the comprehensive material from the tutorial on data management for agentic memory by Guoliang Li, Jiaqi Tian and Xuanhe Zhou. Check out their list of challenges.

Final Thoughts

This trip report was an interesting exercise in self discipline. At conferences, I leave with pictures, copious pointers, and random asides. It takes quite a bit of time to go through the material, think about it, do the Google searches and then write it up. However, I came back from Boston and then immediately got a cold. I was just dragging the whole week and had to catch-up on with folks and many other tasks. I was very tempted to chuck all of the material I had into Claude and then have it ‘help’ me produce this report. Indeed, the result may have been better (an A/B test seems in order?). The AI has seen more material than I could in a week. On the other hand, it didn’t have the nice hallway conversations with colleagues. While I hope, dear reader, you appreciate this report, I think the exercise is also in some sense selfish. It’s a forcing function for me to engage with the material. So in the end I did it the old fashioned way and it’s out later than normal. I don’t know if that was a good decision. For me, this is just another illustration of how AI forces us to decide when we and how we engage our little grey cells.

The rapid changes in AI are clearly causing all of us to think hard about how to do research and what to to research on but luckily for me it made VLDB 2026 a conference that had a lot of great research about subjects that I care about whether its data quality, unstructured data or semantic data management.

Random notes