Best of SQL — March 2026

1
Article
MotherDuck·11w
DuckDB 1.5 is Faster and Easier than Ever
DuckDB 1.5 brings major performance improvements and new features. The new VARIANT type enables automatic JSON shredding for 10-100x faster semi-structured data queries. Min/max queries are 6-18x faster via statistics-based optimization, complex joins now leverage hash joins more broadly, and Top-N-by-group queries can be up to 70x faster. Common Subplan Elimination speeds up complex CTEs. New capabilities include reading entire folders of DuckDB files, writing to Azure Blob and ADLSv2 storage, non-blocking checkpointing with parallel WAL files (17% TPC-H throughput boost), and DuckLake 0.4 with macros and sorted tables.
68
2
Article
DuckDB·11w
Announcing DuckDB 1.5.0
DuckDB 1.5.0 ("Variegata") is now available with a major CLI overhaul featuring color schemes, dynamic prompts, a pager, and last-result access via `_`. Key new features include native VARIANT type support (binary semi-structured data inspired by Snowflake/Parquet), a `read_duckdb` table function with glob support, Azure Blob/ADLSv2 write support, and an ODBC scanner extension. The GEOMETRY type moves into DuckDB core, enabling cross-extension geospatial interoperability, WKB storage, shredding compression (~3x size reduction), geometry statistics for query optimization, and CRS type-system support. An experimental PEG parser ships for better error messages and tab-completion suggestions. Lakehouse updates cover DuckLake spec v0.4, Delta Lake Unity Catalog write improvements, and Iceberg table properties. The httpfs backend switches from httplib to curl. Non-blocking checkpointing improves concurrent RW throughput by 17%. DuckDB 2.0 is planned for summer 2026. The v1.4 LTS line continues until September 2026.
54
1
3
Article
unixsheikh.com·11w
Stop telling people to sanitize user input
A strong argument against the common advice to 'sanitize user input', explaining the important distinction between sanitization and validation. Sanitization modifies data based on assumed intent, risking data loss and misinterpretation, while validation checks that input meets defined requirements without altering it. The correct approach is to validate input, reject non-conforming data, use prepared statements to prevent SQL injection, and encode/escape data at the point of use — not at the point of storage. Client-side validation is also insufficient for security since it can always be bypassed.
50
9
4
Article
Hacker News·11w
Nobody ever got fired for using a struct
A performance investigation at Feldera revealed that SQL tables with hundreds of nullable columns caused significant serialization overhead when mapped to Rust structs. The root issue: rkyv's ArchivedString loses Rust's niche optimization, forcing an explicit Option discriminant, and with 700+ optional fields the archived struct ballooned to 2x the in-memory size. The fix introduces a bitmap-based serialization layout that strips Option wrappers from the archived format and records nullability in a compact bitfield. A further sparse layout stores only present values with relative pointers, dramatically reducing disk I/O for wide, mostly-null rows. The customer's throughput was restored after serialized row size dropped by roughly 2x.
29
5
Article
freeCodeCamp·9w
An Introduction to Database System Design
A beginner-friendly introduction to database system design covering core concepts and practical implementation. Topics include the components of a database system, types of databases (relational, NoSQL, cloud, etc.), the four stages of database design (requirements analysis, conceptual, logical, physical), and normalization through the first three normal forms. A hands-on section walks through designing a library database using PostgreSQL and pgAdmin 4, with SQL examples for creating tables with primary/foreign keys, inserting data, and querying with SELECT, WHERE, and JOIN.
56
6
Article
System Design Codex·12w
What Happens to an SQL Query?
A walkthrough of what happens internally when an SQL query is executed. Starting from the Transport Subsystem handling the connection and auth, through the Query Parser and Query Optimizer producing an execution plan, to the Execution Engine coordinating with the Storage Engine. The Storage Engine's components — transaction manager, lock manager, buffer manager, and recovery manager — each play a role in safely fetching and returning data.
25
7
Article
DEV·10w
Why I, as Someone Who Likes MySQL, Now Want to Recommend PostgreSQL
A long-time MySQL user explains why they now recommend PostgreSQL for new projects. The post acknowledges that many historical PostgreSQL weaknesses (VACUUM complexity, DDL operations, replication) have become less relevant in the managed cloud era. It then details concrete application-level advantages PostgreSQL still holds: ON CONFLICT DO NOTHING vs INSERT IGNORE, the RETURNING clause for getting back changed rows, more natural VALUES usage in JOINs and UPDATEs, window functions in update processing via CTEs, partial indexes, deferred foreign key constraints, pgvector support, and simpler character set/collation handling. The conclusion is not that MySQL is bad, but that PostgreSQL offers clearer advantages for application implementation today.
19
3
8
Article
freeCodeCamp·9w
How to Work With Dapper in .Net
A hands-on guide to using Dapper, a micro-ORM for .NET, to build a Web API backed by PostgreSQL. Covers installation, database seeding, the repository pattern, CRUD operations (query, insert, update, delete), SQL injection protection via parameterisation, batch deletes, transactions, and multi-mapping for JOIN queries. Compares Dapper to Entity Framework, highlighting trade-offs between development speed and execution performance.
17
9
Article
The Daily WTF·8w
Three Minutes
A cautionary tale about a developer (Barry) who, instead of fixing slow SQL queries through proper indexing and query planning, wrote a Python polling script that checks every 3 minutes whether database jobs completed. The script has multiple code quality issues: unnecessary array usage, string comparison against boolean literals, duplicated near-identical queries, and embedded retry logic that bypasses the team's existing job management system. The real fix would have been query optimization with indexes rather than a workaround that masks the underlying performance problem.
28
4

See all SQL archives