Here's a question: Just how short can you write a SQL query?
How about the query "How many volunteers have 7 or more years of experience?"
You can do it in just 36 characters.
Copy code
selectsum(#6>6)from volunteer_ducks
If that looks cursed, you're not alone. And if you've seen worse, you're probably an excel user. Either way, it returns the correct answer. Last month, a bunch of people spent their holidays writing queries exactly like this.
How we got here
We launched the Quackmas 2025 Christmas Heist Challenge on DBQuacks—15 SQL puzzles where you solve a mystery involving missing presents, suspicious volunteers, and millions of GPS coordinates. Hundreds of people competed for prizes.
But a subset of players took on a different challenge: SQL golf. The goal? Solve each puzzle with the shortest possible query.
The results were... interesting. Winning solutions ranged from 36 characters (Challenge 2) to 187 characters (Challenge 4, which required spatial joins across three tables). Along the way, our golfers discovered techniques that are equal parts clever, cursed, and (rarely) actually useful.
Let me show you what they found.
The basics: every character counts
Column position references
Here's the single biggest trick in SQL golf. Instead of writing column names, DuckDB lets you reference columns by position using #N:
Copy code
-- Normal SQLselectsum(missing_count) from missing_presents_report
-- Golf SQL-- `missing_count` is the 5th column in the table `missing_presents_report`selectsum(#5)from missing_presents_report
That's 11 characters saved just on the column name (missing_count → #5). The winning Challenge 1 solution came in at 42 characters. Would I do this in production? Absolutely not. Does it work for golf? Unfortunately yes.
Whitespace elimination
SQL doesn't actually require spaces in most places:
Copy code
-- Readableselectsum(#5) from missing_presents_report
-- Golfedselectsum(#5)from missing_presents_report
The golfers stripped every optional space. where#1=#10 instead of where #1 = #10. Your linter would hate this. But we are golfing!
count() without arguments
DuckDB accepts count() as equivalent to count(*). Two characters saved. In golf, that matters.
Boolean math: the trick that makes you feel smart
Challenge 2 asked: Count how many volunteers have an experience_level of 7 or higher.
The normal approach (64 characters):
Copy code
selectcount(*) from volunteer_ducks where experience_level >=7
Partially golfed:
Copy code
selectcount()from volunteer_ducks where #6>=7
The winning solution (36 characters):
Copy code
selectsum(#6>6)from volunteer_ducks
Wait, what?
Here's the trick: in DuckDB, true evaluates to 1 and false to 0. So sum(#6>6) counts rows where the condition is true. No WHERE clause needed. This reminds me of my favorite Excel Formula, SUMPRODUCT.
And notice: #6>6 instead of #6>=7. Both mean "7 or higher," but >6 saves one character. This is the kind of thing you think about 3 red bulls in during a code golf competition.
The mode() trick: replacing three clauses with one function
Challenge 3 asked: Find the district with the most theft reports. The traditional approach:
Copy code
select district
from duck_households h
join missing_presents_report r on h.household_id = r.household_id
groupby district
orderbycount(*) desc
limit 1
That's a lot of SQL for "give me the most common value."
71 characters. DuckDB's mode() aggregate returns the most frequent value, replacing GROUP BY, ORDER BY, and LIMIT 1 in one function call.
This pattern showed up in Challenges 3, 10, 13, and 14. Anytime you need "the most common X," mode() is your answer. This one's actually useful in real life too.
Join golf: comma syntax is back
Remember learning about comma joins in SQL-89 and then being told never to use them? Turns out they're great for golf.
Every multi-table query in the winning solutions used comma joins. Here's Challenge 7, which asked for the total weight of all missing presents (75 characters):
Copy code
-- Standard JOINselectsum(m.missing_count * p.weight_kg)
from missing_presents_report m
join present_inventory p on m.present_type = p.present_type
-- Winning solutionselectsum(#5*#13)from
missing_presents_report,present_inventory where#3=#8
The comma syntax with a WHERE clause is semantically equivalent to INNER JOIN ... ON. Combined with column position references, join conditions shrink dramatically.
Again, is this readable? No. Does it produce the same query plan? Yes.
DuckDB shortcuts you might not know about
FROM-first syntax
DuckDB lets you start queries with FROM and skip SELECT *:
Copy code
-- Standardselect*from deliveries_log where success =true-- DuckDBfrom deliveries_log where success
Challenge 9 asked: Find all volunteers who rank #1 in at least one district, then count all their deliveries. The winning solution (104 characters) used FROM-first inside a subquery:
The (from table,table where...) pattern creates a derived table without writing SELECT *. I didn't know you could nest from like this until I saw it in the competition, and maybe I wish I hadn't at all.
QUALIFY: filtering without subqueries
QUALIFY filters results after window functions run, so you don't need a wrapping subquery:
Copy code
-- Without QUALIFYselect*from (
select*, rank() over (partitionby district orderby deliveries desc) as rnk
from summary
) where rnk =1-- With QUALIFYfrom summary
qualify rank() over (partitionby district orderby deliveries desc) =1
This one's legitimately useful in production. Window functions are great, but wrapping them in subqueries just to filter is annoying.
The subtraction trick: my favorite solution
Challenge 6 asked: Count how many 5-minute periods in December 2025 have no security checkpoint activity for Coach Waddles (duck_id = 1).
The hint suggested using GENERATE_SERIES to create a date spine. The obvious approach: generate all 8,928 five-minute slots, then find the gaps.
Copy code
with slots as (
select generate_series as slot
from generate_series(
'2025-12-01'::timestamp,
'2025-12-31 23:55'::timestamp,
interval'5 minutes'
)
)
selectcount(*)
from slots s
leftjoin dbquacks_xmas.security_checkpoint_events e
on date_trunc('5 minutes', e.timestamp) = s.slot and e.duck_id =1where e.timestamp isnull
The golf solution (102 characters) flipped the problem entirely:
Total: 1,438 characters to solve all 15 challenges.
Should you golf in production?
No. Your future self (and probably your coworkers) will hate you.
Column position references break when schemas change. Whitespace removal makes queries unreadable. Boolean math obscures intent. This is all terrible for maintainability.
But SQL golf is a great way to:
Learn DuckDB features you didn't know existed:mode(), QUALIFY, and FROM-first syntax are genuinely useful
Think about problems differently: the subtraction trick in Challenge 6 is elegant regardless of character count
Appreciate readable SQL: nothing makes you value linting like debugging select sum(#5*#13)from a,b where#3=#8
Try it yourself
The Christmas Heist challenges are still available on DBQuacks. Think you can beat these scores? Share your attempts in the MotherDuck Community Slack.
Thanks to everyone who participated in Quackmas 2025. Your willingness to write gloriously unreadable SQL made this a blast.
We built a Spotify-style "Wrapped" for MotherDuck employees using our own platform. Discover the SQL queries, data tricks, and fun personas behind our internal leaderboard.
DuckDB news: Iceberg extension adds full DML (INSERT/UPDATE/DELETE). Process 1TB in 30 seconds. Query data via AI agents with MCP server. TypeScript macros for APIs.