--- title: Time to Move On: Querying Without Nulls and Bags | daily.dev description: An academic paper argues that SQL's tolerance of nulls and bag (multiset) semantics is an avoidable design flaw rather than a necessary evil. Drawing on... canonical: https://daily.dev/posts/time-to-move-on-querying-without-nulls-and-bags-85exkjsck twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Time to Move On: Querying Without Nulls and Bags | daily.dev og:description: An academic paper argues that SQL's tolerance of nulls and bag (multiset) semantics is an avoidable design flaw rather than a necessary evil. Drawing on... og:url: https://daily.dev/posts/time-to-move-on-querying-without-nulls-and-bags-85exkjsck og:image: https://api.daily.dev/og/posts/85EXKjsCK.png og:image:alt: Time to Move On: Querying Without Nulls and Bags og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Time to Move On: Querying Without Nulls and Bags **[Hacker News](https://daily.dev/sources/hn)** · 2 min read · 0 upvotes · 0 comments ## Summary An academic paper argues that SQL's tolerance of nulls and bag (multiset) semantics is an avoidable design flaw rather than a necessary evil. Drawing on experience building Rel, a language for end-to-end relational programming built on fully normalized set-semantics relations, the authors debunk the usual justifications for nulls and bags and describe advantages a null-free, set-based query language offers over traditional SQL semantics. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Community take How the wider developer community reacted, aggregated from 1 discussion and 14 comments across hackernews (as of 2026-09-13). **TL;DR:** Developers largely agree SQL is flawed but are skeptical that yet another academic replacement language can overcome SQL's decades of entrenchment and ecosystem lock-in; a substantial side debate questions whether banning bags/duplicates is even correct for real-world data. **Sentiment:** 10% positive · 45% mixed · 45% skeptical **The case for** - Some see algebraic types and set-based semantics as a genuinely better foundation than SQL's null/bag handling. - One commenter argues starting from sets gives nicer constraints around projections and fewer 'crappy errors' than bag semantics. **The pushback** - Many doubt any SQL successor can gain traction given SQL's 50 years of entrenchment and universal tool support. - Some argue eliminating bags is wrong because real-world data legitimately contains duplicate/indistinguishable rows. - The paper is criticized for ignoring algebraic types as the better-known fix for nulls. - Skepticism that a new language solves anything if it only replaces querying and not inserts/updates, forcing developers to learn two languages. - Doubt that breaking from SQL is justifiable in business terms compared to just extending existing SQL dialects. **By community** - hackernews (mixed): General fatigue with 'SQL replacement' proposals mixes with a genuine technical debate over whether banning duplicate rows/bags is actually sound design. **Hottest debate:** Whether bag (multiset) semantics are a real-world necessity for correctly representing duplicate/indistinguishable data, or purely a flaw to be engineered away. **Open questions** - What concrete ecosystem or tooling advantages would make developers actually switch away from SQL? - How would a set-only language handle legitimate real-world cases of duplicate, indistinguishable records? **Highlights** > It has good points, but has 2 major problems, IMHO, that we observed when I was part of a team building a RDBMS: * It again ignore the best solution for nulls: Algebraic types. Once you have this much get solved for free * The argument against bags: The best idea of the paper is that a RDBMS in fact internally do different data structure and temporal representations that are not of concern to the user. Correct. THEN it jumps to the conclusion that bags should not be presented to the user, despite the fact acknowledge it need to display them. This is wrong, and the major reason that is always overlooked is that assume that 2 identical values are wrong to exist. I can have "Jhon, Jhon", be 2 separate persons, not know at this time more to disambiguating, adding a Id do nothing to help me, and yet, this data is correct as is. The language MUST allow me to deal with this. It will absurd to claim an array language, procedural, functional, imperative, declarative, etc can and a relational can't. It say the lang is intentionally limited for purity, that true, is ideal in some cases, but that purity is what the engine/compiler should track, but not distort MY DATA for this. And the part where the perf of having bags dismissed is easy to debunk: implement a dbms and profile. P.D: Is true that set unlocks lots of benefits, and in some cases are ideal. But very fast once you hit the real world you see that need both, similar how btrees alone is not enough, and then there is hash-based indexes and many others. it sucks, but reality is unfriendly to pure pure languages P.D.2: And to clear misunderstanding, I agree with the points in the same way Rust say the borrow checker is ON by default, but I argue we CANT make a strict rule, in special because data is not ideological pure > — [mamcx on hackernews · 2 comments](https://news.ycombinator.com/item?id=49287714) > this is an unfortunate take. btrees do not imply bags. in fact extreme bagginess can be a problem when all the keys in your page are the same. lets take this from the point of view of the user, we can certainly understand that some domain models really want to be set like, and other ones baggy. if the base domain is sets we do get a lot of nice constraints, particularly with semantics around projections and if we want to support bags, its trivial to add a counter for the number of identical records as an additional column. if we want to support sets in bag-land, we could imagine an extension which support 'row unique' on insertion. or we can use a 'unique results' post-filter. so there are paths, but its a lot less clear in a SQL context. you insist that your data demands bags. I really prefer to work in sets and bagginess is always just a source of crappy errors for me. shouldn't we really support usable models for both regardless of the underlying storage? > — [convolvatron on hackernews · 2 comments](https://news.ycombinator.com/item?id=49288639) > It's unfair, but my first thought after reading the abstract was "oh great, another one". There have been several languages claiming to fix SQL and none of them (to my knowledge, I'd love counter examples) have achieved widespread enough adoption to be named a proper successor. Reasons I can guess: - SQL's 50 years of entrenchment- all RDBMSs speak it! Most monitoring systems speak it! Any successor language needs a good interop story so people can use it with their existing systems. - SQL is good enough for run of the mill day to day tasks- and these days by the time I'm lost in recursive queries or window functions, I can ask an LLM for help. Maybe a successor language can win on IDE support or other parts of the dev/agent experience Successor languages also tend to only replace parts of SQL (usually the queries, not the insert/update stuff). I think PRQL does this (once again I'd love to be wrong). Now the dev has to learn two languages? I guess my point is that a successor language, can't just fix the semantic issues with SQL, to be successful it also has to provide large ecosystem (and maybe political) steps up. I didn't see any of that in this abstract, which kills my excitement. > — [bbkane on hackernews · 3 comments](https://news.ycombinator.com/item?id=49287413) > It's very nice that SQL dbs have the same bones such that a migration between them is even reasonable for a small team. That said I've led such a migration, and there's no such thing as "standard SQL" in real practice. You're always going to need extras or optimizations. Rel itself looks really nice, but I have a hard time imagining trying to justify a new query language in business terms. Breaking with SQL completely doesn't seem worth it compared to simply extending or restricting the language like every engine does anyway. Rel seems to offer more than SQL, it's just hard to assess the value. A SQL engine whose dialect enforces unique rows and doesn't include NULL isn't even so different from standard. > — [rivetfasten on hackernews](https://news.ycombinator.com/item?id=49293061) **Source threads** - [hackernews](https://news.ycombinator.com/item?id=49286030) · 40 points · 14 comments ## Similar posts on daily.dev - [Things I want in a modern relational query language](https://daily.dev/posts/things-i-want-in-a-modern-relational-query-language-y0qgepv3u) · Lobsters · 1 upvotes · 0 comments - [SQL Has Rules You Don’t Notice Until Your Query Is Wrong](https://daily.dev/posts/sql-has-rules-you-don-t-notice-until-your-query-is-wrong-ue7ucmkyu) · Medium · 0 upvotes · 0 comments - [The laptop return that broke a RAG pipeline](https://daily.dev/posts/the-laptop-return-that-broke-a-rag-pipeline-nitroecfo) · The New Stack · 0 upvotes · 0 comments - [NULL \!= NULL: How NULLs are ruining your DB with duplicates](https://daily.dev/posts/null-null-how-nulls-are-ruining-your-db-with-duplicates-4kx46ajax) · ITNEXT · 3 upvotes · 0 comments --- Tags: [#sql](https://daily.dev/tags/sql) [View this post on daily.dev](https://daily.dev/posts/time-to-move-on-querying-without-nulls-and-bags-85exkjsck) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Time to Move On: Querying Without Nulls and Bags","url":"https://daily.dev/posts/time-to-move-on-querying-without-nulls-and-bags-85exkjsck","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/time-to-move-on-querying-without-nulls-and-bags-85exkjsck"},"datePublished":"2026-08-13T16:30:55.685Z","dateModified":"2026-09-13T21:34:01.891Z","description":"An academic paper argues that SQL's tolerance of nulls and bag (multiset) semantics is an avoidable design flaw rather than a necessary evil. Drawing on...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/1fed0de190485cbbb37a86fdf656d71b?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/1fed0de190485cbbb37a86fdf656d71b?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Hacker News","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Hacker News","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/hn","url":"https://daily.dev/sources/hn"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/time-to-move-on-querying-without-nulls-and-bags-85exkjsck","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"sql","timeRequired":"PT2M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Hacker News","item":"https://daily.dev/sources/hn"},{"@type":"ListItem","position":3,"name":"Time to Move On: Querying Without Nulls and Bags"}]} ```