I watched Dr. Hipp's keynote. Here's my summary for folks who don't want to sit through it. (This is hand written, not LLM-generated.)
Dr. Hipp suggests a definition of "AI" in which SQL planners are AI, defining AI as "any computing system that performs tasks typically associated with human reasoning, problem-solving, and decision-making." (He then explains briefly how SQL planners are runtime code generators. If you're not familiar with how SQL planners work, the keynote is pretty short and worth a watch.)
He then makes a recommendation to developers who are afraid that AI will take their jobs. He points out that SQL planners kinda take away part of the job of a developer, but really just changed the nature of the job.
He makes his point with a slide:
> Q: How can you avoid being replaced by AI?
> A: Solve more problems than you create.
He concludes with a recommendation against having LLMs generate your SQL entirely. He recommends writing it yourself in order to understand it better and engage both the part of your brain that process human language and the part of your brain that processes formal languages like SQL. (He gives an example of trying to ask a coworker for help, but solving the problem by explaining it to the coworker, and how valuable that experience is.)
---
For my part, I'm not sure I agree with calling a SQL planner "AI" in 2026 (I think that obscures more than it reveals), but the advice to solve more problems than you create will always be wise.
The SQL planner is most definitely "AI", we're just so used to it that it's become trite to say so. I'm having trouble tracking down the version I heard about, but this essentially the "AI effect": "Every time we figure out how to do one of these tings, it ceases to be called AI and just becomes useful software" [0].
Part of the reason I'm dismissive of the current pushback against AI is that people have such a vague definition of it that it starts becoming all inclusive to subsume things like SQL, the Shazam algorithm, etc. Personally, I think it's a good reminder that SQL has quite a bit of intelligence in it. After all, SQL was one of the first mass successes of a declarative based engine.
Put another way, in some abstract sense, one of the differences between SQL query planning and an LLM is one of scale and compute. I wouldn't be surprised that, at some point in the future, we'll see LLM simulation in SQL(ite) akin to how people use different systems to run Doom.
We get to define "AI" however we like, but a definition of AI that includes a SQL planner is so broad that it includes literally all complex software.
When I wrote that a broad definition of AI "obscures more than it reveals," I meant that lumping LLMs in with SQL planners and deterministic chess bots ignores (obscures) all of the details of their implementation.
But those implementation details matter. They have big implications on the uses, limitations, and risks of the software.
As I write this, one of the top stories on HN is a story about an OpenAI model accidentally hacking itself out of Hugging Face's sandbox. SQL planners don't do that. Chess bots don't do that.
That's not to say that saying "all complex software is kinda the same, and we can call all of it AI" doesn't reveal anything. There are some similarities that all complex software has, especially as we look back on the history of complex software and the impact it has had (or not had) on labor productivity.
But, IMO, what you discover by ignoring the details is less important than what you discover by delving in.
I feel that if we're supposed to call a SQL query planner AI, then any compiler that targets more than one architecure (including JIT compilers that optimize for the current processor's cache configuration) should be included as well. And if we're going to be that broad in terms of adaptable command execution then we should be similarly broad in terms of command interpretation, which says to me that all HTML parsers and rendering engines should similarly be classified as AI. After all, SQL queries still follow a very rigid structure and any non-conformant query will be rejected, whereas web engines are very good at recovering from non-conformant HTML input.
I liked his note about how before SQL a lot of people were employed as COBOL programmers to painstakingly write systems that fetched and joined data by hand.
I suggested something similar in an internal chat, i.e. using AI as a tool to help specify, debug and improve your code, rather than delegating all coding to it, and I think the collective response was essentially 'ok grandpa'.
I think we have to expect the majority of SQL queries will soon be machine generated and machine tuned. The planner in database engines will use LLMs. There will be LLM chats to help you specify what query you want to make, and it will work out which tables etc via question and answer.
SQL is in a sweet spot of declarative, formal, and high level. It's basically a description of what the resulting dataset means, not just how to produce it. For ad-hoc queries maybe LLMs take over in the short term, and that's how I read your example. But for core, repeated business logic, human-written SQL seems to still hold value.
is that faster than just knowing what tables you want to run it on? I can see it for agentic but having to chat back and forth every time sounds frustratingly slow for my tastes
Azure DataBricks has something called Genius where you put the tables and views you want to interact with and can talk to it so it constructs a query based on the data you specified. It often does not work completely for me, it either doesn’t get it, or get things 90% there and I need to jump in, decipher the query it came up with and then figure how to change it to what I need. So not sure if the data I am playing with is just too complex/too big, but it’s not working exactly great for me.
As a coincidence, I've just integrated Cesium into my data analytics tool two days ago, https://adsb.exposed/ Though the 3D mode gives a little bit worse image quality, so I keep 2D with Leaflet as the default.
Every keynote, panel, and workshop from this year's Cesium DevCon is now free to watch, no signup. I work in DevRel at Cesium so wanted to flag it here since I don't think it's made the rounds yet.
Highlight for me: Richard Hipp (SQLite's creator) keynoted the opening session, marking 15 years of Cesium as an open source geospatial project. There's also a talk on building a lunar camera digital twin for an actual spacecraft instrument, and a session on Barcelona's underground infrastructure twin, if you want a sense of the range.
I watched Dr. Hipp's keynote. Here's my summary for folks who don't want to sit through it. (This is hand written, not LLM-generated.)
Dr. Hipp suggests a definition of "AI" in which SQL planners are AI, defining AI as "any computing system that performs tasks typically associated with human reasoning, problem-solving, and decision-making." (He then explains briefly how SQL planners are runtime code generators. If you're not familiar with how SQL planners work, the keynote is pretty short and worth a watch.)
He then makes a recommendation to developers who are afraid that AI will take their jobs. He points out that SQL planners kinda take away part of the job of a developer, but really just changed the nature of the job.
He makes his point with a slide:
> Q: How can you avoid being replaced by AI?
> A: Solve more problems than you create.
He concludes with a recommendation against having LLMs generate your SQL entirely. He recommends writing it yourself in order to understand it better and engage both the part of your brain that process human language and the part of your brain that processes formal languages like SQL. (He gives an example of trying to ask a coworker for help, but solving the problem by explaining it to the coworker, and how valuable that experience is.)
---
For my part, I'm not sure I agree with calling a SQL planner "AI" in 2026 (I think that obscures more than it reveals), but the advice to solve more problems than you create will always be wise.
The SQL planner is most definitely "AI", we're just so used to it that it's become trite to say so. I'm having trouble tracking down the version I heard about, but this essentially the "AI effect": "Every time we figure out how to do one of these tings, it ceases to be called AI and just becomes useful software" [0].
Part of the reason I'm dismissive of the current pushback against AI is that people have such a vague definition of it that it starts becoming all inclusive to subsume things like SQL, the Shazam algorithm, etc. Personally, I think it's a good reminder that SQL has quite a bit of intelligence in it. After all, SQL was one of the first mass successes of a declarative based engine.
Put another way, in some abstract sense, one of the differences between SQL query planning and an LLM is one of scale and compute. I wouldn't be surprised that, at some point in the future, we'll see LLM simulation in SQL(ite) akin to how people use different systems to run Doom.
[0] https://en.wikipedia.org/wiki/AI_effect
We get to define "AI" however we like, but a definition of AI that includes a SQL planner is so broad that it includes literally all complex software.
When I wrote that a broad definition of AI "obscures more than it reveals," I meant that lumping LLMs in with SQL planners and deterministic chess bots ignores (obscures) all of the details of their implementation.
But those implementation details matter. They have big implications on the uses, limitations, and risks of the software.
As I write this, one of the top stories on HN is a story about an OpenAI model accidentally hacking itself out of Hugging Face's sandbox. SQL planners don't do that. Chess bots don't do that.
That's not to say that saying "all complex software is kinda the same, and we can call all of it AI" doesn't reveal anything. There are some similarities that all complex software has, especially as we look back on the history of complex software and the impact it has had (or not had) on labor productivity.
But, IMO, what you discover by ignoring the details is less important than what you discover by delving in.
I feel that if we're supposed to call a SQL query planner AI, then any compiler that targets more than one architecure (including JIT compilers that optimize for the current processor's cache configuration) should be included as well. And if we're going to be that broad in terms of adaptable command execution then we should be similarly broad in terms of command interpretation, which says to me that all HTML parsers and rendering engines should similarly be classified as AI. After all, SQL queries still follow a very rigid structure and any non-conformant query will be rejected, whereas web engines are very good at recovering from non-conformant HTML input.
Postgres has a Genetic Algorithm based query optimizer in it: https://www.postgresql.org/docs/current/geqo-pg-intro.html
I liked his note about how before SQL a lot of people were employed as COBOL programmers to painstakingly write systems that fetched and joined data by hand.
I suggested something similar in an internal chat, i.e. using AI as a tool to help specify, debug and improve your code, rather than delegating all coding to it, and I think the collective response was essentially 'ok grandpa'.
I think we have to expect the majority of SQL queries will soon be machine generated and machine tuned. The planner in database engines will use LLMs. There will be LLM chats to help you specify what query you want to make, and it will work out which tables etc via question and answer.
SQL is in a sweet spot of declarative, formal, and high level. It's basically a description of what the resulting dataset means, not just how to produce it. For ad-hoc queries maybe LLMs take over in the short term, and that's how I read your example. But for core, repeated business logic, human-written SQL seems to still hold value.
is that faster than just knowing what tables you want to run it on? I can see it for agentic but having to chat back and forth every time sounds frustratingly slow for my tastes
Azure DataBricks has something called Genius where you put the tables and views you want to interact with and can talk to it so it constructs a query based on the data you specified. It often does not work completely for me, it either doesn’t get it, or get things 90% there and I need to jump in, decipher the query it came up with and then figure how to change it to what I need. So not sure if the data I am playing with is just too complex/too big, but it’s not working exactly great for me.
D. Richard Hipp's 20 minute keynote is here: https://youtu.be/R57nUGzo7CA?is=fDMxVTH_AOvPlKR- (starts 1m45s)
And him receiving a lifetime achievement award here: https://www.youtube.com/watch?v=40v2JFzgEPY&t=4802s
As a coincidence, I've just integrated Cesium into my data analytics tool two days ago, https://adsb.exposed/ Though the 3D mode gives a little bit worse image quality, so I keep 2D with Leaflet as the default.
Hi everyone. I made a file but not really and it speaks SQL and uncle Larry is big mad so totally use it everywhere. You're welcome. Questions?
Every keynote, panel, and workshop from this year's Cesium DevCon is now free to watch, no signup. I work in DevRel at Cesium so wanted to flag it here since I don't think it's made the rounds yet.
Highlight for me: Richard Hipp (SQLite's creator) keynoted the opening session, marking 15 years of Cesium as an open source geospatial project. There's also a talk on building a lunar camera digital twin for an actual spacecraft instrument, and a session on Barcelona's underground infrastructure twin, if you want a sense of the range.
Happy to answer questions about any of it.