About a year ago I started planning QueryCase, where you learn SQL by working detective cases instead of grinding tutorials & videos. It took a while to get off the ground, and longer than I'd like to admit to actually start building the idea, but it went live in June. A lot of the early users came from this sub, and a lot of the feedback in the comments shaped what it became. So first, thanks everyone!

5 months in:

• 2,500+ people have signed up, across 117 countries
• About 70,000 queries written and graded
• Over 17,500 cases, drills and exams solved
• 500+ people have passed the free Rookie exam and earned the certificate.
• Top detective is on 19,247 XP

Since then its grown past just SQL: an Excel course. It was never part of the initial plan. People kept asking for the same detective approach for spreadsheets, so I built out a browser-based Excel engine.

It has 57 cases on a spreadsheet that runs in your browser and checks your formulas, from IF and XLOOKUP to SUMIFS and pivot tables, and people have solved over 2,500 Excel cases so far. It turns out a lot of people learning SQL are doing it alongside Excel, not instead of it.

Something the data showed me that might help anyone learning right now: GROUP BY is one of the first walls. On the hardest GROUP BY step, 84% of runs came back wrong, and most of those never ran at all. The clauses were in the wrong order, or a column in SELECT wasn't in the GROUP BY. If that's you right now:

1. SQL order is always SELECT, FROM, WHERE, GROUP BY, HAVING, ORDER BY, LIMIT
2. Every column in SELECT is either inside an aggregate (COUNT, SUM, AVG...) or listed in GROUP BY

I've been working a lot over past couple months to improve the site as well:

• The Excel course above, with its own ranks, exams and certificate
• Upload your own CSV into the sandbox and query your own data (and visualise in charts). It runs in your browser, so the file never leaves your machine and never touches QueryCase servers
• A free first rank on every track, ending in an exam and a certificate
• SQL interview questions you can read without an account
• Much better experience on a phone
• A LOT of bug fixes and improvements!!

What's next: a Python track, launching next month. Same idea, real Python running in your browser, starting with the basics and moving into data analysis with pandas.

The longer term goal is to have a platform user's can have fun learning all aspects of data. I'm merging PR's every day to make this possible so would love feedback in this thread if you've tried it and have any thoughts or suggestions!

It's free to start and you don't need an account to solve the first case, so you can poke at it before deciding whether it's for you or not 😄 Cheers!

querycase.com

Reviewing a query from a junior on my team. They joined orders to line items, the join fanned out and revenue came out about 3x too high.

Their fix was SUM(DISTINCT order_amount). On our dev data it returns the right total, so they think it's fine and kind of clean.

My gut says it's a time bomb: the day two different orders have the same amount, one of them silently drops out of the total. But "don't do that" isn't a great explanation, and they want a real reason.

How do you explain this to juniors? Or do you actually allow it in some cases?

This sounds stupid; I work in marketing operations, I know how marketing works. What I don't know at this stage of my career is SQL. This has been a major deficit in my life in the last couple of months, where every time I apply for a job I get asked if I know SQL.

What are some free / paid resources to learn SQL so I can get a job.

I built a PostgreSQL Library where you can browse official manuals like real books, search, highlight, and bookmark pages.

Give it a try: https://haiderz07.github.io/postgresql-library/

I’d really value your feedback.

If we group by and use conditions and use aggregate fucntions we are soing the sam ein window fucntions tto, then what is the difference and do they have diffeent implementation?

Genuinely want to hear from people who’ve used both DBeaver and Beekeeper Studio in real work, not just tried them once.

DBeaver Community is free and supports almost every database under the sun, but some people find it clunky. Beekeeper Studio has a free open-source edition plus paid tiers, and it gets mentioned a lot for being cleaner and faster.

Which one do you reach for daily, and why?

If you’ve paid for a database GUI (either one, or something else), was it worth it over the free version? What tipped it for you?

For teams: does anyone share connections or saved queries across the team, and how do you handle that? Do you have a team plan in place with either provider?

Any dealbreakers on either side, like performance, database support, stability, or UI?

Not looking for a best tool ever answer, just real experiences and feedback. Would especially love to hear from people working at larger orgs or with stricter security requirements.

I'm 27M. Hey everyone, my life has been a little different from that of most people, and I don't have a strong educational background.

Right now, I'm working at a grocery store, but I want to improve my life and learn some stable, valuable skills that can help me earn a reliable income.

I've come across these four skills:

Python

SQL

Excel/Spreadsheets

Power BI/Tableau

I don't know much about these skills or their demand, competition, value, and future prospects.

Technology is constantly evolving, trends are changing, and AI is replacing some jobs. The value of different skills also changes over time.

Before I start learning, I want to understand whether these are the right skills to invest my time in for a stable career and income in the long run.

I'd appreciate your advice. Should I go for these skills, or would you recommend something else?

What does the legacy of DORA say about the modern tech industry?

Hi everyone, my name is Salvatore and I work as a Data Analyst / Data Engineer.

Recently I ran into a problem related to Power BI incremental refresh on large, mostly append-heavy fact tables.

In the specific case, the issue was eventually solved by revisiting the data model and redesigning the star schema. However, working on it made me think more deeply about some of the problems that can arise when large amounts of data are managed through partitions.

In particular:

• even a relatively small number of new records can end up involving multiple partitions that need to be processed;
• some partitions can grow much larger than others over time and therefore become more expensive to refresh;
• very wide fact tables, especially those containing many high-cardinality columns, can increase the processing and memory cost of the model;
• on very large models, the combination of these factors can lead to very long refreshes and, in the worst cases, timeouts.

In Power BI, for example, a standard refresh on Premium capacity has a five-hour limit, so on very large datasets the way records are distributed across partitions can become relevant as well.

This led me to wonder whether it makes sense to separate two problems:

1. identifying which records have changed;
2. controlling which partitions, and how many of them, need to be rebuilt.

From there I started experimenting with an approach based on stable technical classes.

The basic idea is fairly simple.

During the initial load, each record is assigned to a class_id between 1 and N using a modulo-based distribution. The mapping between the stable record key (source_key) and its class_id is then persisted, so that once a key has been classified, it continues to belong to the same class in subsequent runs.

The class_id therefore becomes the technical key I use to control downstream partitions.

For new INSERTs, instead of distributing them across all classes every time, I use a round-robin assignment only within a subset of classes.

From this idea I ended up with two variants.

1. Rotating Window

It selects a window of K consecutive classes and distributes new INSERTs only within that window. In subsequent runs, the window rotates through the class space.

2. Least-Loaded

Instead, it selects the K classes that currently contain the fewest records and distributes the new INSERTs only among those classes.

In both approaches, K represents the maximum number of classes that an INSERT batch can automatically involve. An adaptive policy is therefore used to allow smaller batches to use a smaller sub-window — or, more generally, a smaller subset of classes — than this maximum.

For example, with K max = 10:

INSERT <=    500 -> K = 1
INSERT <=  5,000 -> K = 4
INSERT <= 20,000 -> K = 7
otherwise        -> K = 10

So a very small batch may involve only one partition, while larger batches can progressively use more classes up to the configured maximum.

I implemented both ideas in T-SQL for SQL Server, including persistent state, a PREPARE/FINALIZE lifecycle, automated tests, and some exploratory benchmarks.

Here are the complete reference implementations with README, code, tests, and benchmarks:

Rotating Window Partition Refresh
https://github.com/Salvatore97710/rotating-window-partition-refresh

Least-Loaded Class Partition Refresh
https://github.com/Salvatore97710/least-loaded-class-partition-refresh

These are reference implementations / prototypes, not solutions I would consider production-ready.

What I’m mainly looking for is technical feedback on the idea itself.

Do you see any conceptual problems I may be missing?

And more importantly: if you were facing the same problem — a large append-heavy fact table and the need to control both the number and the size of the partitions being refreshed — how would you approach it?

I've been building a query language where a program is a pipeline of stages in execution order: from → filter → group by + aggregate → having → sort → take, compiled to DuckDB SQL. The bet is that keyword order (SELECT before FROM, HAVING after GROUP BY) is the wrong mental model.

Two design choices I'd like critiqued:

1. Splitting group by and aggregate into separate stages — clearer for beginners, or just more lines?
2. Rejecting chained comparisons and bare select before from with stage-located errors — helpful guardrails or unnecessary restrictions?

The grammar is frozen at v1.5 (spec in the repo); I'm more interested in what you'd change than in stars: https://github.com/absterjr/UNSeQueL

Disclosure: Idea was mine, initial setup was mine, but it started getting more and more complex while using a local LLM and now I'm stuck.

spent some time cleaning up runtime.school this week.

the lessons and practice are less busy now, the editor feels better, and i went through the course so questions only use sql that has actually been taught by that point.

i also kept the beginner lessons and practice on the same dataset so it’s easier to focus on the sql before switching contexts.

if anything feels confusing, off, or harder than it should be, let me know.

https://www.runtime.school/

​

I've been working on this one for a while, some new features, made a demo tape below

I added a pure TDS based custom assembly to allow SQL Server support (Yes I know duckdb has a community Ms SQL extension , but I made one that works better with my daffy product, my internal component is daffysql ) and a new bulk parquet export automation feature. currently mounted to 500 tables from a combo of SQL server tables, postgres tables, Excel sheets, & CSVs? one proc call writes 500 new parquet files.

connect to it from any SQL Server client, Ado, power bi, ssms, etc. i put together this demo of the new features, let me know what you think. very similar to how Babel fish for postgres works but this one is duckdb + more.

it's on nuget and code signed by azure

https://youtu.be/jTzbJsPn8jE?is=jMZIKm5TooYoyf8v

Scott

two correct queries over the same 1,390 rows: one rounds to 33223.80, the other to 33223.81. the exact decimal sum is 33223.8050, exactly half a cent, and in DOUBLE the order the rows get added decides which side it lands on. a window over monthly subtotals adds them in one order, a correlated subquery over the raw rows adds them in another.

i hit this because the checker in a SQL game i make (DuckDB in the browser) failed the second query on the visible sample and passed it on both hidden sets. here's how that checker decides a query is right, the other places it was wrong, and the part i still don't know how to handle.

how it checks: every problem has a reference query. when you submit, yours and mine both run on the sample data you can see, then on two datasets you can't, generated from other seeds. boss problems get four, labelled ties and duplicates, sparse groups and boundary dates. the sample always runs so you can see a diff, then it stops at the first hidden set that fails and says which one. a hidden set where my query returns zero rows gets skipped, since an empty result would let an empty answer pass.

then the two result sets get compared. column names are matched as a set, case-insensitive, so column order doesn't matter as long as the names are unique. row order only matters if the prompt asks for a sort. integers have to match exactly. fractional values get an absolute tolerance the problem sets, usually 0.0001, so on a money column it's tighter than a cent. NULL matches NULL. a DATE matches the same day at exactly midnight as a TIMESTAMP, because generate_series and date_trunc('day', ...) hand you timestamps and a correct "one row per day" answer was failing.

where it was wrong:

the tolerance was relative at first, tol * max(|a|, |b|). so on a big dollar total a "2 cents" check was actually a percent check, and a total that was 1.9% off passed on every seed. now it's absolute plus a tiny term for float noise.

Infinity passed against any finite number, because abs(inf - x) <= tol + inf is true. a later audit caught it.

for unordered results i used to sort both sides and zip them. that breaks once tolerance is involved: tiny values written in scientific notation sort differently as text, so a correct answer could get paired with the wrong row and fail. now it builds a which-row-can-match-which graph and does a bipartite matching (building the graph is quadratic, which is part of why results are capped at 5,000 rows).

then in october i ran 141 alternate answers, other ways to write each reference query that i expected to pass, through the same normalizer and comparator. 108 passed. a lot of the failures were my prompts, where a sentence had two readings and the visible sample couldn't tell them apart. one asks for deciles of users by lifetime notional, and if you include users with no trades at 0 you pass the sample and fail both hidden sets, because the sample has no non-traders and the hidden sets, built at a quarter of the size, have 74 and 91. a few more were regex checks i use to require a certain style of query, refusing equivalent ones. and one was the engine. on the duckdb-wasm build i'd shipped (DuckDB 1.5.1), this

SELECT user_id, asset_id
FROM wallet_balances_daily
WHERE user_id BETWEEN 1 AND 3
QUALIFY ROW_NUMBER() OVER (PARTITION BY asset_id, user_id ORDER BY balance_date DESC) = 1
ORDER BY user_id, asset_id
LIMIT 3

came back with user_id and asset_id swapped (the table has user_id first). native 1.5.3 got it right and so does wasm 1.5.4, which the demo build runs now, though i never tracked down the upstream issue.

this week's audit found two more. those boss labels promised more than the data did: the sets were mostly re-rolls of the same generator, so a >= 1800 written for "strictly more than 30 minutes" passed all three session problems. the next build plants real boundary rows and gap days in one hidden set. and the half cent above. the fix is one rounding unit of tolerance on the 10 columns where a half cent can happen, not a looser check everywhere.

the one i haven't solved is ties. a top-N pick (LIMIT n, rn <= n, QUALIFY) can fail a correct query if two rows tie at the cut and the prompt's sort key doesn't break the tie, and an ordered result has the same problem with ties anywhere in it. a september audit on native DuckDB checked all 48 top-N picks on every graded seed: no tie at a cut, 13 that a data change could expose. fee_usd has 600 tie groups across the graded seeds, the nearest about 1,600 rows from its cut. for now a script checks that on demand and the prompts name a tiebreaker where they can.

i don't log query text from players, only counters, so i can't tell you what people actually typed. the counters are small: over oct 1-14 the demo showed its "too few rows" nudge 12 times and "too many rows" 5 times.

for people who've built graders for interview tools or internal tests: do you compare aggregates as DECIMAL, give each column its own tolerance, or make the prompt require a specific ROUND? and for ties, is there a way that doesn't make the prompt name the tiebreaker? that works, but it hands over part of the answer.

This is a small SQLite example of a point-in-time correctness problem: an event happened before a prediction, but the pipeline only received it afterward. A historical feature query can accidentally use information that was unavailable at prediction time.

The two synthetic captures below use integer USD cents. The prediction cutoff is January 2. e2 happened on January 1 but arrived on January 3.

WITH events(
  event_id, customer_id, currency, amount_minor,
  event_time, received_at
) AS (
  VALUES
    ('e1', 'c1', 'USD', 1000,
     '2026-01-01T12:00:00Z', '2026-01-01T12:00:00Z'),
    ('e2', 'c1', 'USD', 2500,
     '2026-01-01T15:00:00Z', '2026-01-03T12:00:00Z')
), cutoff(ts) AS (VALUES ('2026-01-02T00:00:00Z'))
SELECT customer_id, currency,
  SUM(CASE WHEN event_time < ts
           THEN amount_minor ELSE 0 END) AS event_time_only,
  SUM(CASE WHEN event_time < ts AND received_at <= ts
           THEN amount_minor ELSE 0 END) AS available_at_prediction
FROM events CROSS JOIN cutoff
GROUP BY customer_id, currency;

Verified in SQLite: the result is c1 / USD / 3500 / 1000. The first amount includes e2; the second excludes it because it was not yet received. No future event timestamp is needed for the leak.

A few boundaries matter:

• This example deliberately uses identically formatted UTC strings, so lexical timestamp comparison works here. Normalize offsets and formats before applying this pattern to mixed source timestamps.
• received_at represents availability in this toy model. In a real feature pipeline, receipt may precede validation, transformation, or serving; use the timestamp that reflects actual availability for the prediction you are reconstructing.
• This only models captures. Refunds, corrections, duplicates, and versions require their own rules. Keep the currency in the grain.
• The event-time upper bound is exclusive and the availability bound inclusive here; choose and test the convention explicitly.

I maintain a free MIT-licensed fintech data engineering practice repository. Its C08 scenario extends this into delayed labels and temporal splits using Python and SQLite. The query above is self-contained; no clone is needed to reproduce it.

Disclosure: I maintain the linked project; its first edition and this post were prepared with AI assistance using Codex. All data here is synthetic.

For people who reconstruct historical features: do you retain a separate feature-availability timestamp, or derive it from versioned publication batches? How do you represent corrections that arrive after the original event?

I've found this query as a solution to the famous Pizza Runner case study, and I am stuck at figuring out what COUNT() returns, compared to COUNT() OVER().

I know OVER() does the count (or whatever aggregation) over the entire dataset, but idk I'm just not getting the percentage part of this query.

Help :)

​

Hey everyone!

I've been learning SQL for a while and have reached a point where I can write queries using joins, CTEs, subqueries, aggregate functions, window functions, and other concepts. I'm also trying to apply what I've learned through projects and case studies rather than just solving isolated exercises.

However, I'm struggling with a different part of the process.

I can write a query, execute it, and get the output, but I'm often unable to understand what those results actually mean for the business or the problem I'm trying to solve.

For example, suppose I'm working on a case study where user engagement has declined. I can query the data, calculate daily active users, compare different periods, break down engagement by user segments, and identify changes in the numbers.

But then what?

How do I determine whether those changes are significant? What questions should I ask next? How do I distinguish a genuinely useful insight from an observation that's technically correct but doesn't tell us much? And how do I connect the numbers to a possible business problem or recommendation?

I understand that this is where analytical thinking, business understanding, and judgment come into play. But these concepts feel quite abstract when I'm actually sitting in front of a dataset.

I'm trying to understand how analysts develop this skill in practice.

- Is this something that primarily develops through working on more projects and case studies?

- Are there particular frameworks or approaches I should follow when interpreting query results?

- How do I learn to ask better questions instead of simply querying whatever data is available?

- Are there any books, resources, or projects that specifically teach the thinking process behind data analysis, rather than just SQL syntax and tools?

I'd especially appreciate advice from people working as data analysts or data scientists who have faced this problem themselves.

I don't necessarily want someone to interpret every result for me. I want to develop the ability to look at data, reason about what I'm seeing, decide what to investigate next, and eventually arrive at defensible conclusions.

How did you learn to bridge the gap between writing SQL queries and actually thinking like an analyst?

Thanks in advance!

What do you do to check data quality, consistency, uniqueness and nulls, when you you medallion to model tables together.Are there specific guide or steps you take to ensure everything is just like expected?

Hi all- are there certificates out there that’s provide hands-on learning/ practice on SQL, SAS , Python etc In USA

Which to learn first?

Anyone else got a copy of this?

From back when you actually got manuals with software. Apparently written by Larry Ellison himself (which I doubt, even then!).

One nice feature is the description of the dept and emp tables is actually a fold out from the back page, so you have it side by side on whatever page you are reading.

Covers the basics of SQL in a concise 33 pages, including a small bit on security and on string functions.