SQL in Google Sheets: Query External Data Without Leaving Your Spreadsheet

Most companies treat spreadsheets as the data graveyard — the place where information goes to die after export. Someone runs a query, exports CSV, imports it into Sheets, formats it. A week later, the cycle repeats. And again. And again.

That’s not analytics. That’s manual labor pretending to be analysis.

What most people don’t know is that Google Sheets supports direct SQL queries against external data sources. I’m not talking about paid connectors or third-party tools. I’m talking about native functions that turn a cell into a live query, updating in real time.

The real problem: static data in a dynamic world

Think about the typical data analysis workflow in most small to mid-size companies:

1. Someone exports data from the system
2. Imports it into Google Sheets
3. Creates formulas and charts
4. The spreadsheet becomes stale in days (sometimes hours)
5. Repeats the process

This cycle creates two concrete problems:

Hidden operational cost. Someone is spending hours moving data manually. Time that never shows up on a report, but burns through the week.

Decisions based on outdated information. By the time the spreadsheet is finally updated, the situation has changed. You’re looking in the rearview mirror while driving.

The solution: SQL directly in the cell

Simon Willison, creator of Datasette, recently documented a technique that solves exactly this: using Sheets’ IMPORTDATA and IMPORTHTML functions combined with APIs that accept SQL queries via URL.

The logic is straightforward:

1. You have a data source exposed via API (Datasette, Supabase, or any backend that accepts SQL over HTTP)
2. You construct the SQL query as part of the URL
3. Use IMPORTDATA() in Sheets to pull the result directly into a cell
4. The spreadsheet updates automatically

The result is a cell that works like a live query. Not a snapshot — an actual connection to the source.

Practical example with Datasette

Datasette is an open-source tool that turns any SQLite database into a navigable API. If you have data in SQLite (and many people do without realizing it — it’s the backup format for several systems), you can expose it like this:

https://your-server.com/database.json?sql=SELECT+name,+value+FROM+sales+WHERE+date+>+‘2025-01-01’

In Google Sheets, that becomes:

=IMPORTDATA(“https://your-server.com/database.csv?sql=SELECT+name,+value+FROM+sales+WHERE+date+>+‘2025-01-01’”)

Done. The cell now contains the query result. Updating every hour automatically (or on demand).

What this changes in practice

Traditional workflow

• Manual data export
• CSV import every week
• Data goes stale in days
• Formulas break with changes
• Time spent on maintenance

With SQL in Sheets

• Direct query to source
• Automatic updates
• Always real-time data
• Stable structure via SQL
• Time spent on analysis

The real impact isn’t technical — it’s operational. You eliminate an entire category of repetitive work. And more importantly: decisions are based on current data, not snapshots from weeks ago.

When to use (and when not to)

This approach works well for:

• Operational dashboards that need frequent updates
• Recurring reports that currently depend on manual export
• Exploratory analysis where you want to test queries quickly
• Teams that live in Google Sheets and won’t migrate to traditional BI

It doesn’t work well for:

• Very large data volumes (Sheets has row limits)
• Complex queries requiring heavy JOINs (performance degrades)
• Sensitive data that can’t be exposed in URLs (queries are visible)
• Scenarios where you need granular access control

• Does your data source have an API or can it be exposed as one (Datasette, Supabase)?
• Does the data volume fit within Sheets’ limits (≈10M cells)?
• Can the query be expressed in simple SQL?
• Is the data non-sensitive enough to be part of a URL?
• Does your team already work in Sheets and resist new tools?

If you checked 4 or 5, it’s worth testing.

What this means for real analytics

BI tools like Metabase, Looker, or Power BI exist for good reasons. They solve problems spreadsheets can’t: governance, versioning, complex visualizations, controlled access.

But most small to mid-size companies live in a different reality. There’s no budget for enterprise BI. There’s no data team. What exists is Google Sheets — and it’s already open in everyone’s browser.

If your team lives in Sheets, the pragmatic solution is making Sheets work better — not forcing a migration that won’t happen.

Implementation: where to start

If you want to test this in practice:

1. Choose a data source. If you have data in SQLite, Datasette gets you up in minutes. If you use Supabase or have a REST API, you’re ready. If your data lives in MySQL/PostgreSQL, you need an intermediary layer.

2. Build a simple query. Start with a basic SELECT. Test the URL in your browser before putting it in Sheets.

3. Use IMPORTDATA() with CSV format. Most APIs let you specify output format. CSV is cleanest for Sheets to parse.

4. Set up refresh. By default, Sheets refreshes imports every hour. To force more frequent updates, use a dummy parameter in the URL that changes (like a timestamp).

5. Build on top. Once data is flowing in, use normal Sheets formulas to transform, filter, and visualize.

The real point

Analytics isn’t about sophisticated tools. It’s about having the right data, up to date, in the place where decisions happen.

For many companies, that place is a spreadsheet. That’s not embarrassing — that’s reality.

The right question isn’t “which BI tool should I buy.” It’s: how do I get data where my team already is, without friction, without delay, without repetitive manual work?

SQL in Google Sheets is one possible answer. Not the only one, but one that works with what you already have.