Beyond tables: how visual data tools are changing work

Open any database tool, spreadsheet, or business intelligence platform, and you'll see the same thing: rows and columns. Data lives in grids. Queries return tables. Dashboards arrange charts in rigid layouts.

This paradigm has been the default for decades. But a new category of tools is challenging it — and the people who've tried working with data visually aren't going back.

Why grids aren't enough

Tables are great for structured, linear data. But real-world data has shape. Customers connect to orders. Orders connect to products. Products belong to categories. Projects have tasks, tasks have assignees, assignees belong to teams.

When you flatten these relationships into a grid, you lose the spatial understanding of how things relate. You can describe the relationships in SQL joins or formula references, but you can't see them.

Tools like Notion and Airtable recognized this early. They gave users multiple "views" of the same data — galleries, kanban boards, calendars, timelines. It was a step forward, but the underlying model was still a table. You were looking at the same grid through different lenses.

The canvas approach

A canvas is fundamentally different. Instead of viewing data through a fixed layout, you place data objects on an infinite spatial surface. You can arrange tables next to each other, draw connections between them, group related data visually, and build a layout that matches how you actually think about the domain.

The idea isn't new in other fields. Architects use spatial layouts. Designers work on canvases. Miro and FigJam proved that spatial, collaborative surfaces work brilliantly for brainstorming and planning. The question was always: why not for data?

The answer was technical. Data tools need to be backed by real query engines. You can't just drag sticky notes around — you need those spatial relationships to translate into actual data operations. Dragging a column from one table to another should create a real join, not just a visual line.

Visual queries vs. written queries

SQL is powerful. It's also a barrier. According to Stack Overflow's Developer Survey, SQL is one of the most-used programming languages — but that still leaves the vast majority of knowledge workers who don't write code at all.

Visual query builders have existed for years, but most feel like a clunky GUI wrapper around a text input. They translate buttons and dropdowns into SQL, which means you still need to think in SQL terms.

A canvas-based approach is different. Instead of "SELECT column FROM table WHERE condition," you drag the column you're interested in, connect it to a filter, and see the result. The interaction model matches the mental model — you're manipulating data objects directly, not writing instructions for a computer to follow.

Who benefits most

Visual data tools aren't just for non-technical users. Power users who already know SQL benefit too. Seeing your data model laid out spatially helps you spot patterns, understand schemas faster, and build more complex queries than you might attempt in a text editor.

Builders and makers — people who use tools like Airtable, Notion, or Coda to run projects, track clients, or manage content — are the natural audience. They're already comfortable with flexible, modular tools. A data canvas extends that flexibility to actual database operations.

Analysts and operators — people who pull reports, answer ad-hoc questions, and build dashboards — benefit from seeing data relationships visually rather than holding them in their head while writing queries.

Small teams without data engineers — when there's no one to set up a Metabase instance or write dbt models, a visual tool that works directly with your data removes a dependency.

The trade-offs

Visual tools aren't universally better than text-based ones. For complex analytical queries involving window functions, CTEs, or recursive queries, SQL remains more expressive. The best approach is probably both — a visual interface for exploration and everyday work, with the option to drop into SQL when you need precision.

The key is that the visual layer shouldn't be a gimmick. It needs to be backed by a real database engine, so the interactions produce real results, not approximations.

Shard puts your data on a canvas backed by a real SQLite database. Drag tables, connect data visually, query by dragging columns — or drop into SQL when you need to. It's database power with a builder's interface. Sign up free and see data differently.