SQL or Death? Seminar Series – Spring 2025
db.cs.cmu.edu
db.cs.cmu.edu
Also, Malloy has done something clever. They embed duckdb into their VSCode extension, so you can easily query (and join) .csv or .parquet files on the fly. I laugh when I think of all the time I spent noodling with pandas code to do simple data cleaning, analysis, or joining. This also means that you can press "." on any github repo and start querying.
I teach MS Business Analytics students - they really enjoyed walking through an analysis of first names given in the USA for the past century. To see it, click to the github repo [1], press ".", install the Malloy extension, click back to the names1.malloynb file and run the queries.
[1]: https://github.com/malloydata/malloy-samples/blob/main/names...
No, it's the morass of the interactions between GROUP BY/ORDER BY/HAVING. Like, why isn't there FIRST statement to select the first element in the group?
It's perfectly possible to do `SELECT * FROM blah LIMIT 1`, after all.
Even now, the default behavior of SQLite is still "undefined" if a Select column doesn't appear in Group By. Well, to be precise it's a single "arbitrary chosen row" used to sort the results. https://www.sqlite.org/lang_select.html#resultset
I'm not bagging on SQLite here (I love it!), but I am bagging on SQL 'cuz EVERY implementation must make far too many of these sorts of Faustian bargains.
SQL:
SELECT country, MAX(salary) AS max_salary
FROM employees
WHERE start_date > DATE '2021-01-01'
GROUP BY country
HAVING MAX(salary) > 100000
from employees
filter start_date > @2021-01-01
group country (
aggregate {max_salary = max salary}
)
filter max_salary > 100_000You'd think that you should be able to sort by the house ID, then by the sale price, then group by the house ID, and select the sale _date_ from the first row of each group.
Something like: `select s.house_id, first(s.date) from sale s order by s.house_id, s.price asc group by s.house_id`. But this is impossible, because there's no `first` function in SQL.
But nope, you need DB-specific extensions for that.
In any case, you can do this with a subquery and join it with the main table. I don't think there's anything non-standard about it:
SELECT hs.*
FROM house_sales hs
JOIN (
SELECT house_id, MIN(price) AS min_price
FROM house_sales
GROUP BY house_id
) min_prices
ON hs.house_id = min_prices.house_id AND hs.price = min_prices.min_price
Either one is fine.
PostgreSQL has an extension (DISTINCT ON) that allows to do what I want without subqueries. But standard SQL is simply deficient in this regard, it should be straightforward but it's not.
Row_number() over (partition by x order by) as rank
Then: where rank = 1.
Grouping is unordered, which is a clean definition.
With SQL, it is a trial and error. When your query passes your sniff tests, you sign looks good to me, and you ship it to the world. Only to silently break shortly afterwards without any warning.
In enterprise, I am convinced at this point that all of the complex ETL jobs are vending wrong outputs. Just nobody has the tools to diagnose and fix the problems.
It is also the syntax because it does not match the actual model. Even the simple example `SELECT 1` shows a mismatch.
And this cascade. Because the syntax is wrong, people have big trouble with `JOINs` (that is disconnected from the idea of making `?-to-?` specifications), `group by` (that doesn't exist in SQL), aggregation logic (that is badly implemented as window functions), and bigly, the lack of composability (that has a weird band-aid called CTEs) and so on.
A mismatch between the domain and the code is always reflected in syntax.
For me, it's the lack of SQLs expression composability. And yes, I'm well aware of various libraries and plug-ins that purport to yield "composable SQL". It's never gonna' happen at-scale due to decades of investment in query optimizers for the popular relational engines.
Just make peace with all of SQL's warts or go NoSQL and make piece with code-bloat and eventual consistency.
>Imagine a programming language without functions. You can only write code that operates on concrete values, i.e. variables or literals. So instead of writing a function and calling it anywhere you have to write these little code templates as comments and every time you want to “call” the “function” you copy the template and do a search/replace.
>This would be tiresome. But that’s what SQL is. The concrete values are the table names. The code is the queries. And the function templates you have to search replace are your business logic, which must be inlined everywhere it is used.
After discovering the truth, it was interesting to find out that almost everyone I knew who wasn't a snr db engineer shared the same incorrect assumption.
you cannot make a language fast, only its underlying implementation (i.e the specific dbms).
and this is the error I see 90% of the time. there is a confusion between conceptual (model) vs implementation concerns.
the problem with SQL the language is its conceptual foundations -- that it is not currently relational and yet it is used as the language of "relational" DBMSes in the market.
The more higher-level expressions your languages supports, the more work its compiler (whether targeting physical or virtual hardware) must do to translate those ASTs into "machine" code and the higher the variance of that code during its execution workload.
It's even more work when that language's expressions are declarative instead of imperative.
If a DBMS is "slow" or "fast", that is not because of SQL -- it is because of the specific implementation decisions that the makers of that DBMS took.
And that has nothing to do with what you just said.
"The talks in this series will present ideas on either (1) making SQL go as fast as possible or (2) replacing SQL with something better."
How were you able to infer that the existence of the word "go" in that phrase refers to optimizers?
And 2nd idea/proposal of "replacing SQL with something better" really implies that they are talking about the language and not the optimizer.
In any case, if they really meant "optimizer" then their phrasing is very vague and imprecise; if they are talking about the "optimizer" -- then which specific optimizer? They have failed to mention that too.
SELECT book->>'name' FROM books;
Without an additional "id" column, inserting a new book with a unique id becomes cumbersome.
Who wrote this? What are they trying to do here? Be funny? Stop that.
C or Death? Lets replace C with Rust.
SQL or Death? Lets replace SQL with NoSQL and now back to SQL and to something else?
HTML or Death? Lets replace everything with JS client side rendering.
PDF? JPEG? AAC? H.264 / AVC? x86 / ARM [1]? Every single thing that is 10 - 20 years old are considered old fashioned and we need to rip them apart without learning about their merits and pitfalls they went through. And sometimes as Alan Kay said only to reinventing the flat tire.
How about Better C? Better SQL? Better JPEG? etc And most if not all the time it isn't the language or spec that is the problem. It is the implementation. I am willing to bet we wont even have an Open Source SQL implementation that is as good as today's Oracle or MS_SQL in 10 years time. There are still insane amount of work on implementation alone.
It seems the Tech industry as a whole is in an eternal philosophy battle of throwing away everything and build something new vs improving what we have today and iterating on it.
[1] A prominent Intel engineers once said by the time you learn everything about Hardware design pitfalls from GPU to CPU and different ISA and be ready to design something truly so much better you will be at the age of retirement. I think this sort of hold true in other areas as well.
We are absolutely learning from the pitfalls of our previous technology to make better things. It's not perfect but we're moving forward. It's not fast fashion, it's more like the car/vehicle industry.
Older developers who cannot tell the difference between a website built 20 years ago vs today or think the developer experience of working with rust vs c++ is just aesthetic are digging their heels in to their own ignorance
This just isn’t a problem. There are more than enough programmers in the world to explore different approaches to common problems. We all ultimately learn and benefit from those experiments. The cycle of reinvention isn’t some great failure that requires fixing. It's how progress works.
And yes, people will not understand everything about what exists or has existed before trying something new that may or may not work out. We're humans, not robots. We don't have perfect memory and we don't have the bandwidth to ingest every bit of wisdom that has come before us, so inevitably we will retread some of the same mistakes that have been made or rediscover things that have already been discovered. That's called learning.
> It seems the Tech industry as a whole is in an eternal philosophy battle of throwing away everything and build something new vs improving what we have today and iterating on it.
At what point do iterations become so different or just completely ideologically opposed that it stops being compatible with the language? Should we get rid of malloc and free in C? What if the extension I want to add to the language is rejected by the governing board? What if the file format is proprietary and requires a license? What if it's belongs to a company like Oracle or Microsoft and contributing to its development is only possible if you work for them?