SQL Reporting in Airtable Without Writing SQL

Every Airtable base eventually reaches a reporting ceiling. You add a reporting table, fill it with linked records, layer on rollup fields to get averages and totals, and then build a second reporting key when one link field is not enough to slice the data the way the business wants. What you are actually doing at that point is rebuilding a pivot table by hand, one field at a time.

There is a better tool for this job, and it has existed for fifty years: SQL. It is the query language that runs most of the internet, and it is what Airtable uses under the hood — you just have no access to it. This tutorial covers a custom interface that gives you that access, without requiring you to write a single line of SQL.

Video Tutorial

Why Airtable Reporting Hits a Wall

Native Airtable reporting is built on relationships. A rollup field can only summarise records that are linked to the record you are looking at. A lookup follows the same rule. The pivot table element inside Interface Designer works well for a single table with a couple of grouping dimensions, but it runs out of flexibility as soon as the question gets more specific.

Three limits show up again and again in real bases:

• Unlinked tables cannot be combined. If your employees table and your sales table have no link field between them, there is no native way to put monthly sales next to monthly headcount. Creating the link field is often wrong from a data-modelling perspective — those records genuinely have no relationship to each other.
• Reporting tables are maintenance. Each new question means new linked records, new rollups, and new formula fields. The base grows sideways, and six months later nobody remembers which of the four "Reporting" tables is the live one.
• Ranked and windowed questions are effectively impossible. "Top three earners per department, with the gap to their department average and to the company average" is a normal management question and a routine SQL query. In native Airtable it is a project.

SQL answers all three in a single query, because it joins on matching values instead of relationships, computes on demand instead of storing intermediate fields, and supports ranking and running totals as first-class operations.

What the Business Analyst Engine Does

The Business Analyst Engine is a custom Airtable interface extension that sits inside your base and turns a written question into a report. The flow is:

1. You type a question in plain English — "list all countries across every table that has a country field, and show which table each one appears in."
2. The extension sends your question, together with the schema of the tables you selected, to Airtable AI.
3. Airtable AI returns a SQL query.
4. The extension executes that query against your actual Airtable data and renders the result as a table.

The critical detail is step four. The AI writes the query. It does not produce the numbers. The figures you see come from running the query against your records, which is why the results hold up on tables with tens of thousands of rows — and why you can sense-check them the way you would check any database output.

A 50% launch discount runs for the first two weeks after the video goes live.

Walking Through Real Queries

The demo base holds five tables: employees (with hire date, termination date, salary, and location), departments, sales (customer, country, date, amount), inventory (electronics with country of origin, category, specs, and ratings), and a countries table used for testing. Four of them are connected to the interface — which tables the extension can see is a setting, not something hard-coded.

Auditing values across unlinked tables

The first query asks for every country appearing anywhere in the base. The AI generates the query, runs it, and returns 13 countries scanned across the connected tables.

Adding "show me which table each country comes from" to the same prompt and re-running rewrites the query. The first attempt returns the data ungrouped, so the next refinement is simply "group it by country" — the interface is conversational, and each instruction reshapes the query rather than starting over.

The result exposes a classic data-quality problem: the United Kingdom appears in the sales and employees tables, and "UK" appears separately elsewhere. Asking the interface to treat United Kingdom as UK adds a conditional to the generated SQL, and the count drops from 13 countries to 12:

SELECT
  CASE WHEN country = 'United Kingdom' THEN 'UK' ELSE country END AS country,
  source_table,
  COUNT(*) AS appearances
FROM combined_countries
GROUP BY 1, 2
ORDER BY 1;

A final instruction adds a total row at the bottom: 76,000 rows across all the tables in scope. That number is worth pausing on — this is a full scan of the base, executed in an interface element, returned in seconds.

Monthly sales with year-to-date and headcount

The second query targets the sales table: 2025 sales by month, with one column for the monthly total and a second for the year-to-date running total. Then comes the request that native Airtable cannot satisfy — "also add the count of employees we had in those months."

That data lives in the employees table, which has no link to sales. The first generated query returns a reference error. Resubmitting feeds the error back into the next generation, and the corrected query works: it derives headcount by checking each employee's hire date and termination date against each month, then joins that to the monthly sales aggregate.

Extending it further to show employees added, employees terminated, and the net difference per month produces a query that is genuinely long — and running across roughly 26,000 rows of employee and sales data. Because the numbers come from execution rather than generation, they reconcile: total headcount, joiners, leavers, and the month-on-month delta all line up when you check them against each other.

SELECT
  month,
  SUM(amount)                                    AS monthly_sales,
  SUM(SUM(amount)) OVER (ORDER BY month)         AS ytd_sales,
  headcount,
  hires,
  terminations,
  hires - terminations                           AS net_change
FROM monthly_sales
LEFT JOIN monthly_headcount USING (month)
GROUP BY month
ORDER BY month;

Pivots, rankings, and the vocabulary trap

On the inventory table, a query asking for the average rating of phones grouped by category comes back with a single category. That looks broken until you open the table: only one category in the data is actually a phone — iPhone. Everything else is a laptop, a tablet, or another device class.

This is the one habit the interface demands. Ask in the vocabulary of your data. Swap "phones" for "computers" and three categories are returned. Swap it for "inventory" and you get everything. The AI matches against the field values that exist, not against the category you had in mind.

From there the same base supports the report types that normally justify exporting to a spreadsheet:

• A classic pivot: categories down the side, average price across memory-size columns.
• Bottom-N rankings: the worst-rated models within each category, ranked per group.
• Windowed comparisons: the top three employees by salary in each department, shown next to the department average, the gap to that average, and the gap to the company average — all grouped by average department salary.

Every result panel has a CSV download, so anything that needs to move into a board pack or a finance system does. And every query is saved in the sidebar, renameable and re-runnable — which turns a monthly reporting pack into a list of saved queries instead of a rebuild.

Adding the Interface to Your Own Base

The package includes a shared base you can copy and use as-is, plus the source code if you want the extension running in your own project. Adding it to an existing base takes a few minutes.

1. Get the extension. Copy the shared base from the package. Open its single interface, and use the option in the top-right corner to either edit or download the source code.

2. Create a custom interface element in your base. In your own base, go to Interfaces, choose to build it yourself, and create a new interface. The important part is to generate it with Omni and give it a prompt that Omni cannot satisfy with a standard element — the prompt used in the video is "build me a map interface showing employees." Because there is no native map element that does this, Omni is forced to write a custom code component, which is exactly the container you need. If you are new to this, our guides on building interfaces with Airtable Omni and custom Airtable interfaces with code cover the basics.

3. Paste in the source code. Open the generated element, choose edit source code, replace it with the Business Analyst Engine code, and save changes.

4. Create the AI Helper table. The extension needs a bridge to Airtable AI. Create a table called AI Helper containing:

• One record named SQL formula
• A text field called Input
• An AI field called Result, configured to take the Input value

In the AI field settings, switch the model from the default to a stronger reasoning model, set generation to automatic rather than manual, and turn off tools — the field only needs to return text. No other tables or fields are required.

5. Connect the data and permissions. Back in the interface element, open the data panel and select the AI Helper table plus every table you want to query. Then enable Edit records inline and allow editing on the AI Helper table — the extension writes your question into the Input field, which is what triggers the AI field to produce the query. Publish the interface.

Once it is running, watching the AI Helper table makes the mechanism obvious: the extension writes your question plus the schema and instructions into Input, the AI field returns the SQL into Result, and the extension executes what comes back.

Where This Fits in a Reporting Stack

This interface is not a replacement for every reporting tool, and it is worth being clear about where it wins.

It replaces the reporting table. If your base has a table that exists only to hold linked records and rollups so somebody can read an average, this removes the need for it. The question gets asked directly against the source data.

It complements interface dashboards. Charts, KPIs, and record lists still belong in a normal Airtable dashboard — they are better at ambient, always-on monitoring. This is for the ad-hoc analytical question that a dashboard was never designed to answer. Our guide on charts and graphs in Airtable covers the visual side.

It reduces the export habit. Teams that pull data into a spreadsheet every month to build the pivot they actually need can do it in the base instead, then export the result if it needs to travel. For heavier BI needs, connecting Airtable to Power BI is still the right call.

It sits alongside client reporting. If you produce recurring reports for clients, the saved-query list becomes the source for the numbers that go into a client reporting dashboard. Our reporting and dashboarding solutions page covers how we structure this for teams.

For context on what Airtable's AI layer can and cannot do more broadly, see our review of Airtable Cobuilder and our explainer on what Airtable Omni is.

Business Use Cases

• Finance and operations. Monthly revenue with running totals, cost per department against headcount, and variance against averages — without maintaining a reporting table for each view.
• HR and people ops. Joiners, leavers, and net headcount by month; salary distribution and outliers by department; tenure analysis from hire and termination dates.
• Sales. Performance by month, region, or customer with ranking and year-to-date columns, and comparisons against team or company averages.
• Inventory and product. Pivot-style price and rating analysis across category and specification, plus bottom-N reports that surface the products dragging a category down.
• Data quality audits. The country query in the demo is a data-cleaning exercise as much as a report — finding inconsistent values across tables that nobody linked is exactly what a scan-everything query is good at.

Limits and When to Get Help

Two constraints are worth knowing before you build a process around it.

The first is the vocabulary issue above: the AI writes queries against the values in your fields, so vague or mismatched terminology produces confidently wrong-looking results. Well-named tables and fields make a large difference to output quality.

The second is scope. This is a reporting and analysis layer. It reads your data and returns tables — it does not write records back, trigger automations, or replace a warehouse for cross-system reporting that spans Airtable, your accounting platform, and your ad channels.

That is usually where a build starts. Consider bringing in help when:

• Reports need to be delivered on a schedule rather than pulled on demand
• The numbers must combine Airtable with an external system such as Xero, Stripe, or a data warehouse
• Different roles need different data visibility within the same reporting interface
• Query results need to drive downstream automations in Make
• The base structure itself is the real problem, and the reporting difficulty is a symptom

We build custom Airtable interfaces and reporting systems at Business Automated. Talk to our Airtable team if you want this adapted to your base and your reporting cycle.

Next Steps

• Get the Business Analyst Engine, copy the shared base, and run the sample queries against the demo data before touching your own base
• Make a list of the reports your team currently rebuilds by hand each month — those are the queries worth saving first
• Audit your base for reporting tables that exist only to hold rollups; most of them stop earning their place once queries run directly against source data
• Review your field and table naming, since it directly affects the quality of the SQL the AI generates
• Read our reporting and dashboarding solutions page to see how this fits into a wider reporting setup

Airtable was never going to give you a SQL console. But the data is relational, the AI can write the queries, and the interface layer is open enough to connect the two — which is enough to stop rebuilding pivot tables out of rollup fields.