How to turn a spreadsheet into a database you can query

You can turn a spreadsheet into a database two ways, and the split matters. For a normal file, Zo reads your CSV or Google Sheet during a chat and answers in plain English with zero setup. For a big file or one you query all day, it loads the data into SQLite, a single data.db next to your files, and runs real SQL instead.

Key takeaways

• The zero-setup level works today. Zo reads a CSV, .xlsx, or connected Google Sheet during a chat or an automation and answers in plain language, no SQL and no database file.
• The database level is for scale. When a sheet is large or you ask the same questions daily, Zo loads it into SQLite so queries run as real SQL against an index instead of re-reading the file.
• SQLite on Zo needs nothing installed. Bun ships the driver, so the database is one file, data.db, beside your other files on your own server.
• The tipping point is cost. Re-reading a giant file on every question burns tokens and runs slow. That repeated cost is the signal to load a database and query it cheaply after.
• A deterministic script does the load, so you never pay an AI to read your data row by row, and you own the file, so you can grep, sync, and back it up.
• The database goes stale if the sheet changes and nobody rebuilds it. Rebuild on a schedule, and keep the send guardrail on any automation that reports numbers.

What does it mean to turn a spreadsheet into a database?

Turning a spreadsheet into a database means moving your data from a grid you scroll to a structure you query. A database stores your rows in a form a query engine can filter, group, and join in milliseconds, without loading the whole thing into memory first. With Zo, natural language spreadsheet queries work either way. You ask in plain English, and Zo decides whether to read the file directly or run SQL underneath.

A database is not required to ask questions about your data. You need one when asking gets slow or expensive.

Should you just ask it, or load a real database?

Start cheap and graduate only when it hurts. This is the spreadsheet to database split, drawn plainly.

Most people live in the left column and never need the right one. A founder checking last month's sales against a 400-row export is done in one prompt, and only starts eyeing the right column once that same question takes longer and costs more each time it runs.

How do you query a spreadsheet with AI and no setup?

Export the sheet to CSV, drop it in your workspace, and ask. To query a spreadsheet with AI this way, Zo reads CSVs, .xlsx files, JSON, and connected Google Sheets directly during a run, with nothing to install. You ask, Zo opens the file, and it answers. That is chat with your spreadsheet in its simplest form.

Here is a prompt to hand Zo verbatim. Swap the path and questions for your own.

Read Data/sales-2026.csv. It has columns: date, region, product, units, revenue.
Answer these:
1. Total revenue by region, highest first.
2. The single best sales day and its revenue.
3. Any month where revenue fell more than 15% from the month before.
Show the numbers in a small table. If a column is ambiguous, tell me your assumption before you answer.

That last line matters. It forces Zo to name how it read a fuzzy column instead of guessing, the difference between an answer you trust and one you check by hand.

This works inside an automation too, not just a live chat. A scheduled run has the same file access you do, so a Monday job reads the export and texts you the three numbers you care about. Every run spends credits whether or not it notifies you, so match the interval to how often the data changes. The Zo automations guide covers scheduling, and conditional delivery keeps a report quiet unless a number crosses a line you set.

When should you load the spreadsheet into a database?

Load it when reading the file every time stops being cheap or fast. If Zo has to ingest a 200,000-row export to answer one question, it pays that full reading cost on every single question, and a big re-read fired on a schedule quietly runs up credits for work a query would do once.

A database flips the math. You read the file once at load, into a SQLite table with a real index, and after that "revenue by region for Q2" is a SQL query that touches only the rows it needs and returns in milliseconds. The question stays plain English, and Zo writes the SQL. A deterministic query does the counting, so you never loop an AI over N rows when one query settles it.

How do you convert a CSV to SQLite on Zo?

You describe it, Zo builds it. SQLite needs nothing installed because Bun ships the driver in the runtime, so the whole database is a single file like data.db in the same folder as your CSV. Nothing to configure, no service to rent.

Ask for the load like this.

Load Data/orders.csv into a SQLite database at Data/orders.db.
Infer the columns and types from the header and first rows, and write a deterministic loader script so I am not paying per row to import it.
Create an index on customer_id and order_date.
Then answer: top 10 customers by total spend, and repeat-order rate by month.
Show me the SQL you ran.

Two details earn their place. "Write a deterministic loader script" keeps the import mechanical instead of an AI reading each line. "Show me the SQL you ran" lets you check the query matched the question, so you catch a wrong join before it becomes a wrong number in a report that goes out with your name on it. The SQLite-as-a-file guide walks the same pattern on a Site, and when you outgrow SQLite you can run a real database on Zo with no Docker.

Where does the database actually live, and why does that matter?

It lives in your workspace as one file, and that ownership is the quiet advantage. Because data.db is a file on your own server, you can open it, grep it, sync it to your laptop, and back it up by copying the folder. Zo has a built-in SQLite explorer, so you click the file and read the rows without writing a query. A rented SaaS spreadsheet tool cannot give you that. Zo is a computer that acts on your files, so the database sits next to your automations, Space pages, and other data, and every one of them can reach it directly. Move the project, and the data moves with it.

What goes wrong when you turn a spreadsheet into a database

The failure modes here are boring and predictable, which is exactly why you can plan for each one long before it turns into a wrong number in a report you already sent. Five of them.

Messy headers and merged cells. A spreadsheet built for human eyes often has a title row, merged cells, or two header rows stacked, and Zo can trip on those and map a column wrong. Export a clean single-header CSV, or tell Zo which row is the header.

Zo guessing a column's meaning. A column named amt could be revenue, cost, or units, and left to guess, Zo picks one and answers with confidence. Name your columns in the prompt, or add the "tell me your assumption first" line so a wrong guess surfaces early.

Token cost on a big re-read. The zero-setup level re-reads the whole file on every question, which on a huge sheet asked on a schedule is real credit burn. When you feel it, load the database.

Stale data after the sheet changes. A database is a snapshot from load time, so an edited spreadsheet leaves data.db wrong until someone rebuilds it on the schedule the source changes. Watch for the silent version too: a connected app's token lapses, the schedule keeps firing, the load fails, and the run looks fine from outside. Tell the automation to flag a failed pull, never to treat missing data as zero.

The send guardrail. An automation only messages out through a delivery channel you turn on, and Zo leaves emails as drafts unless you tell it to send. If a job queries the database and writes you a summary, keep the human gate on anything outbound, and give an unattended persona only the scopes it needs so it has no path to message anyone else. Every run saves as a real conversation, so when a number looks off, you open the run and read the query that produced it.

Frequently asked questions

Can I ask questions about my data without building a database?

Yes. Zo reads a CSV, .xlsx, JSON, or connected Google Sheet directly during a chat or an automation and answers in plain English with no setup. You only need a database when the file is large, or you ask the same questions often enough that re-reading it gets slow and expensive.

How do I convert a CSV to SQLite on Zo?

Ask Zo to load the CSV into a SQLite file next to it, like data.db. Bun ships the driver, so nothing needs installing. Zo infers the columns, writes a deterministic loader script so you are not paying per row, then answers your questions as SQL queries you can inspect.

Does turning my spreadsheet into a database cost a monthly fee?

No. The SQLite database is a single file on your own Zo server, not a hosted service you rent, so there is no separate bill. You pay AI credits for the runs, and pricing is at zo.computer/pricing.

What happens if my spreadsheet has messy headers or merged cells?

Zo can misread a title row, a merged cell, or stacked headers and map a column wrong. Export a clean CSV with one header row, or tell Zo which row is the header. Asking Zo to state its assumptions catches a bad guess before it reaches a number.

How do I keep the database from going stale when the sheet changes?

Rebuild it on the schedule your source data changes on. A database is a snapshot from load time, so an edited spreadsheet leaves the data.db out of date until a rebuild. Have the scheduled load flag a failed pull instead of treating missing data as zero.

Is SQLite enough, or do I need Postgres or DuckDB?

SQLite handles most personal and small-team data, from an order log to a few hundred thousand rows. Reach for DuckDB for fast analytical scans over large tables, and Postgres only for heavy concurrent writes. If you cannot name what SQLite is failing at, you have not hit that wall.