Early in our company’s life, we built everything around modern data frameworks — until we realized the simplest, most reliable tool had been in front of us all along.
SQL is not just a “query language” — it’s one of the few truly declarative tools we have. It lets you express what you want instead of how to get it. Decades of engineering have made it fast, stable, and expressive — qualities that align naturally with our emphasis on reliability and structure.
Over time, much of modern software has tried to hide SQL behind layers of abstraction. We went the other direction. Leaning into it — especially through DuckDB — made our data workflows simpler, faster, and easier to reason about.
The Quiet Miracle of SQL
SQL isn’t new. It was designed in the 1970s by IBM researchers, yet it still runs much of the modern world. Banks, airlines, telecom systems, logistics networks — the infrastructure we all rely on — still depends on it. That longevity isn’t inertia; it’s evidence of a design that got the fundamentals right.
SQL was created by people solving real, critical problems: consistency, concurrency, recovery, and correctness at scale. The result was a language that’s both rigorous and flexible.
At Sturdy Statistics, we’re drawn to tools that are stable, composable, and well-designed — and SQL’s design philosophy echoes that perfectly. The same principles that made SQL powerful in the 1970s — a clear data model, declarative syntax, and a query optimizer that handles complexity for you — still make it powerful today.
A Common Language for Humans and Machines
SQL’s enduring power lies in its declarativity: you describe relationships and constraints, and let the system figure out how to satisfy them. It’s one of the few languages where you can express your intent clearly and still let the system handle optimization for you.
It’s also composable and set-based rather than iterative — closer to algebra than to imperative code. These properties make SQL expressive enough for complex analysis and simple enough for inspection. The same query can run locally, or distributed across a cluster, without any change in syntax or meaning.
This became especially clear when we decided to treat SQL not as glue code, but as a primary language for analysis. When we started moving more of our logic into SQL itself, our data pipelines got smaller, faster, and easier to understand. For us, SQL is a thoughtful, well-designed language for reasoning about our data. It forces structure to be explicit, so both people and programs can see exactly how the pieces fit together.
Why DuckDB
DuckDB is small, embedable, and perfect for analytical workloads. It gives you the performance of columnar storage, the simplicity of local execution, and the reliability of a real database. Its API is compact but expressive, and its support for function chaining and higher-order operations makes it a natural fit for our workloads.
At first, local execution might sound like a limitation; in practice, it’s the opposite. Today’s CPUs are astonishingly fast. We run our analysis on Apple M4 Ultra chips, and it would be difficult to saturate them on a real-world data task. Distributed processing would be significantly slower for our use cases, especially once you factor in network latency. DuckDB lets us process our data where it is, and keeping computation close to the data has sped up our entire pipeline dramatically.
DuckDB fits our broader design philosophy: composing self-contained, minimal, transparent systems, which use the right tool for the task at hand.
What We’ve Learned
While we do have a fondness for old tools at Sturdy Statistics, we didn’t choose SQL out of nostalgia. For us, SQL is simply the right tool for certain jobs: it makes reasoning easier, encourages clarity in our code, and executes reliably.
In a field often obsessed with novelty, SQL reminds us that some problems were already solved — beautifully — decades ago. Sometimes the best progress comes not from replacing old tools, but from rediscovering how well they still work.