Map the data tooling landscape by weight, and it splits into two clumps with a hole in the middle.

On one end are the platforms — Snowflake, Databricks, the warehouses, the orchestration suites, the “AI-powered enterprise data quality” products. They are real and they are powerful, but a lot is demanded before anything is returned: accounts, provisioning, connectors, billing, governance, onboarding. The data is expected to live inside them.

On the other end is a sprawl of tiny browser tools, most of them spun up on DuckDB-WASM in the last two years. SQL playgrounds. CSV-to-JSON converters. Query editors that open in a tab. They are free, private, local, and nearly interchangeable — there are dozens of them, because the technology made them trivial to build.

In between, where most of the actual work happens, there is almost nothing good. That middle is the interesting part. The gap is real, it is wider than is usually admitted, and it stays empty for reasons that have nothing to do with how hard it is to build.

The two ends are crowded; the useful middle is empty — for reasons that have nothing to do with difficulty.

Most data pain is mid-sized

The work that eats a week is rarely warehouse-scale and rarely a one-liner.

A vendor sends an extract that does not match last month’s. Finance flags a number and the rows that moved have to be found. Two files that should reconcile do not. A schema drifts and nothing warns anyone. A CSV carries a column that is mostly null, and that should be caught before it breaks a downstream job. None of this needs Spark. None of it needs a cluster, a workspace, or a six-month rollout. But none of it is comfortable to do by hand every single time either.

That is the mid-sized layer — too small for a platform, too repetitive to keep solving manually. By volume it is where a huge amount of real engineering time goes. It is also the layer the market serves worst.

Why the middle stays empty

The easy explanation is that the middle is technically hard. It is not. DuckDB and WASM made local analytical tooling genuinely easy to build — which is exactly why the SQL-box end is so crowded. So if it is easy, why is the useful part so thin?

A few reasons, and none of them are about technology.

The wrong user gets designed for. Almost every data tool is built by a data engineer, and engineers build for people like themselves. So the default interface is a SQL box in the center of the screen. Fine for the SQL-literate. But it quietly shuts out the analyst, the finance person, the ops lead, the consultant — everyone who has the messy file and the real question but does not want to write a windowed aggregate to answer it. The tool that would fill the middle has to care about the non-technical user, and that is the product work most engineers skip, because it is not the fun part.

Generic wins on ambition and loses on usefulness. The instinct is always to build the general thing — the universal data quality platform, the everything-workbench. But a generic tool speaks nobody’s language. It does not know what a freight manifest looks like, which columns matter to a property manager, what the standard export from a given industry’s ERP actually contains. The useful middle is mostly vertical, and vertical is unfashionable. It means picking one narrow audience and learning their files cold instead of building the impressive abstract thing.

There is no clean business model, so nothing gets finished. The middle does not monetize like a platform. Seat-based SaaS pricing cannot be charged for “give me the file, I will tell you what changed, then you leave.” So the funded players ignore it — too small — and the indie builders abandon it half-done — no revenue. What is left is a graveyard of weekend projects that nailed the first 80% and never shipped the part that made them trustworthy.

Feature creep drags everything toward the platform end. Every tool that starts in the middle feels the pull. Inspect a file, and then saved projects are wanted. Then history. Then scheduled checks, then notifications, then users to receive them, then permissions for the users, then audit logs for the permissions — and the nimble little tool is now a junior platform fighting the giants on their own turf. Staying in the middle takes discipline, because staying small reads as a lack of ambition rather than a deliberate boundary.

What the middle actually wants

The tools that belong in this gap share a shape. They are workbenches, not platforms. A platform wants to own the workflow; a workbench helps with one job and gets out of the way. The files stay where they are. The work does not get trapped inside somebody’s product.

What the middle is hungry for is sharp, single-purpose tools for the thankless work — file comparison and diffing, schema-drift detection, profiling a messy extract, inspecting Parquet, a validation report that can be handed to someone, a reconciliation check that answers what changed without a project plan. Local-first, so sensitive files never have to be uploaded anywhere. Deterministic at the core, so the output is evidence and not vibes — and where an AI layer exists, it should narrate and summarize, never be the source of truth. And ideally vertical: built for one audience’s real file formats instead of for an abstract “data user” who does not exist.

None of that is a moonshot. That is the point. The middle is not empty because it is beyond reach. It is empty because it is unfashionable to build.

Why it is worth building anyway

A disclosure is fair here: I build in this gap. Small browser-based data tools are something I actually ship at Anatini.dev, not just theorize about, so this is not a neutral observation. But shipping into the middle is what made the gap feel real. The engine was the easy part. The difficulty was all in resisting every pull toward the platform end, and holding the tool to one honest promise: give me the file, I will help you understand it, then you can leave.

The market is loud about the two ends. The platforms have the budgets and the keynotes; the free SQL boxes have the GitHub stars. The quiet middle has neither, which is exactly why it stays underserved — and exactly why it is the most interesting place to build right now.

DuckDB and the tools around it did not just make the warehouse optional for small jobs. They made a whole class of nimble, local, honest tools possible. So far that capability has mostly been spent building the same SQL editor forty times over. The real opening was always the gap before the warehouse — and that gap is bigger than anyone admits.