SQLite logo

Embedded file

Connect SQLite to Excel, Google Sheets, AI and REST

One .sqlite / .db file as a database. For a folder of SQLite files that should union into shared tables, use SQLite Folder instead.

Start free 13 destinations

One connection, every surface

Where your SQLite data can go

SQLite live tables · read-only
Federated queries + any other connector · one SQL across sources · every plan
Network Agent
  • 1 outbound connection
  • 0 inbound ports
  • read-only · credentials stay put

runs on

Query Streams turns a single SQLite file into something Microsoft Excel, Google Sheets, Power BI, an AI assistant over MCP or a REST call can read, without moving the file anywhere. Point the agent at a path — a local disk, or a network share typed as \\server\share, never a mapped drive letter — and it opens the file read-only, in place. If an application already has the file open, there is a switch that reads it anyway without taking a lock, which is the usual reason a SQLite file is considered unqueryable.

  1. For your team, vendors and partners

  2. SQLite to Excel Microsoft Excel · Excel add-in

    Pull live SQLite results straight into a worksheet and refresh them on demand — desktop Excel, Excel Online, Microsoft 365.

    SQLite guide

  3. SQLite to Google Sheets Sheets add-on

    Run a saved SQLite query from the sidebar and drop the rows into the sheet. Shared collaborators can refresh it themselves.

    SQLite guide

  4. Ask Nova about SQLite Nova AI · text to SQL

    Ask a question in plain English. Nova already knows your SQLite tables, writes and runs the SQL, explains the answer and charts it — no query to write, no credentials to hand over.

    How Nova works

  5. SQLite to Data Viewer result sharing · team, vendors, partners · phone, tablet, desktop

    Share a live SQLite result with anyone — a colleague, a vendor, a partner — as a bookmarkable grid that re-runs fresh when opened, on a phone, a tablet or a desktop. They see the results, never the SQL or the credentials.

    How the Data Viewer works
  6. For apps and systems

  7. SQLite REST API HTTP endpoint

    Publish a SQLite query as an authenticated JSON endpoint any application can call, with an OpenAPI 3.1 spec and ready-made Postman, Insomnia and Hoppscotch collections. No database port is opened.

    SQLite guide

  8. SQLite to Power BI Power Query M

    Paste the generated Power Query M into the Power BI Advanced Editor and the report reads live SQLite results over HTTPS — no ODBC driver, no database port opened.

    How Power BI works

  9. SQLite to Airtable Automation platform

    Sync SQLite rows into an Airtable base on a schedule, or fetch them inside an Airtable automation script.

    SQLite guide

  10. SQLite to Baserow Automation platform

    Feed a Baserow table from SQLite over the REST endpoint — self-hosted or Baserow cloud.

    SQLite guide

  11. SQLite to SeaTable Automation platform

    Keep a SeaTable base current with SQLite data without exporting a file or exposing the database.

    SQLite guide

  12. SQLite to Smartsheet Automation platform

    Push SQLite results into a Smartsheet grid so plans and reports read from the source system, not last week's export.

    SQLite guide

  13. SQLite to Anvil Anvil Works · App platform

    Back an Anvil Python app with SQLite through the REST endpoint instead of embedding database credentials in the app.

    SQLite guide
  14. For AI tools

  15. SQLite MCP server Claude, Cursor and MCP clients

    Give an AI assistant read-only access to SQLite with the schema it needs to write correct SQL — no credentials in the chat.

    SQLite guide
  16. Delivered to people

  17. SQLite alerts and reports Slack · Discord · Email · Webhook

    Put a SQLite query on a schedule and have the rows delivered to Slack, Discord, email or a signed webhook — or hold the message until a row count, threshold or percentage change crosses the line you set.

    How alerts and reports work

How it works

5 steps, no inbound firewall change

01

Install the Network Agent on a machine that can already see the file. It never leaves that machine.

02

Browse to the .db, .sqlite or .sqlite3 file. A local path works, and so does a share typed as \\server\share\file.db; a mapped drive letter does not, because the agent runs as a service and cannot see it.

03

If the file is written to by a live application, turn on immutable mode so it is read without taking any lock at all.

04

The agent reads the table and column layout so the Query Builder can offer real names. An encrypted file is opened with the passphrase you supply.

05

Write read-only SQL, or let Nova write it. Read the saved query from Excel, Sheets, Power BI, MCP or REST.

Feature deep-dive

What SQLite gives you

Reading a file that something else is using

SQLite's locking is what stops most reporting tools dead: the application that owns the file holds it, and the report either blocks or fails. Immutable mode is the way out, and it is a deliberate choice rather than a hidden default.

  • Immutable mode opens the file with no locking at all, so a live application keeps working and your query still returns.
  • It is opt-in on purpose. It tells SQLite the file will not change while it is being read, which is the right promise for a report and the wrong one for a file being actively rewritten by a long transaction.
  • Left off, the file is still opened strictly read-only — the driver itself refuses to write, on top of the statement check that runs before anything is sent.
  • Nothing is copied. There is no temporary snapshot, no upload, and no second version of your data to keep track of.
  • The journal mode of the file is reported back on the connection test, so you can see whether it is running in WAL before deciding.

An encrypted file is fine

  • An encrypted SQLite database opens with the passphrase you supply. It is held on the agent, like every other credential here.
  • Views are listed alongside tables, so a file that keeps its reporting logic in views is browsable as it was designed to be.
  • Indexes are read too, which is how the Query Builder knows what will be fast.

One file, or a folder of them

This connector is for a single file. If what you have is a folder of SQLite files with the same shape — one per store, one per day, one per customer — the SQLite Folder connector unions them into shared tables and tells you which file each row came from.

-- local_db is the connection; SQLite's only schema is main
SELECT   o.status, COUNT(*) AS orders
FROM     local_db.main.orders      o
JOIN     pg_crm.public.customers   c ON c.id = o.customer_id
GROUP BY o.status

Shared by every database connector

True of every database connector

  • Outbound only — the agent opens one encrypted connection out to Query Streams. No inbound port to forward, no VPN, no IP allowlist, nothing about your database exposed to the internet.
  • Credentials stay put — the database username and password live on the machine you installed the agent on. Query Streams never receives them and cannot reach your database on its own.
  • Read-only, enforced — one statement at a time, SELECT and friends only. A write is rejected on your own machine before it is ever sent to the server, rather than relying on a permission somebody remembered to set.
  • Deploy as many agents as you like — one per site, region or cloud. Every data source they can see arrives in a single dropdown, so nobody has to know which agent hosts what.

What you get once a query is saved

  • Share the capability, not the SQL — a colleague or an outside partner can run your query and change its filters without ever seeing the statement behind it.
  • Filters from either direction — declare them yourself as @variables, or let the connector spot the literal values already sitting in your WHERE clause and offer those as dropdowns.
  • Read it from anywhere — Microsoft Excel, Google Sheets, Power BI, the REST API, AI assistants over MCP, the Query Builder and Nova all read the same saved query.
  • Run several at once — five saved queries into five worksheet tabs, streamed concurrently, however large the results.
  • Join it to anything else you have connected — another database, a business API, or a folder of files, in one read-only statement.

Cross-source SQL

Join SQLite to the rest of your data

One statement can span SQLite and your other connections at once. Each source runs only the part it can, streams the result back, and the join happens centrally — the sources never talk to each other and nothing is copied anywhere.

3 connections · 3 agents

SQLite Embedded file
PostgreSQL Relational engine
Stripe Payments & billing

One statement

-- nothing copied, nothing merged, nothing scheduled
SELECT   c.region, COUNT(*) AS orders, SUM(i.amount_due) AS invoiced
FROM     local_db.main.orders1    f
JOIN     pg_crm.public.customers2 c ON c.id = f.customer_id
JOIN     billing.stripe.invoices3 i ON i.customer = c.stripe_id
GROUP BY c.region
ORDER BY invoiced DESC;

The three parts are connection, schema and table — and the connection name is whatever you called it. Illustrative columns; your tables will be your tables. Read-only applies to every piece: SELECT, WITH and EXPLAIN only, with a ceiling on how much any one source may hand over for a single query. How federated queries work

Connection details

What SQLite needs

What you point at
One .db, .sqlite or .sqlite3 file on the agent's machine, or on a network share typed as \\server\share (mapped drive letters are not visible to the agent's service)
Opened
Read-only at the driver, not merely by convention
Locked files
Immutable mode reads a file another application holds open, taking no lock
Encryption
An encrypted database opens with a passphrase, held on the agent
Driver
Microsoft.Data.Sqlite 9.0.2, bundled — nothing to install
Copies
None. No snapshot, no temp file, no upload
Schema
SQLite has one, called main, and that is what a federated reference uses
Read-only
Enforced before the statement runs, and again by the open mode

The file never leaves the machine the agent is on. What travels is the result of your query, over the agent's own outbound connection — so a SQLite file on a machine behind a firewall is readable from a spreadsheet without that machine being reachable from anywhere.

In a cross-source query the middle part of a three-part reference is main, SQLite's only schema — not the file name. A connection called local_db is written local_db.main.orders.

Vendor documentation: www.sqlite.org

FAQ

Questions about SQLite

Which tools can read SQLite data through Query Streams?

All of them, from one connection: Excel, Google Sheets, MCP, REST API, Airtable, Baserow, SeaTable, Smartsheet, Anvil, Power BI, scheduled alerts and reports. Connect the database once and every surface reads the same read-only connection — there is no per-tool setup and no second copy of the data.

Do I have to open a firewall port to my SQLite database?

No. The Query Streams Network Agent runs inside your network and opens a single outbound encrypted connection. Nothing listens for inbound traffic, no VPN is required, and the database keeps its existing firewall rules.

Can Query Streams change data in SQLite?

No. The agent enforces read-only at the point of execution — one statement at a time, SELECT and friends only. Credentials stay on the agent and are never sent to Query Streams.

What does Query Streams need to connect to SQLite?

A reachable host, a role and its password — the agent carries the driver, so nothing is installed on the database. What you point at: One .db, .sqlite or .sqlite3 file on the agent's machine, or on a network share typed as \\server\share (mapped drive letters are not visible to the agent's service). Opened: Read-only at the driver, not merely by convention. Locked files: Immutable mode reads a file another application holds open, taking no lock. Encryption: An encrypted database opens with a passphrase, held on the agent.

Can I join SQLite to another database in the same query?

Yes — that is a federated query. One statement can reference SQLite and your other connections at once, written as connection.schema.table. Each source runs only the part it can and streams the result back; the join happens centrally, so the sources never connect to each other and nothing is copied or scheduled. Read-only applies to every piece — SELECT, WITH and EXPLAIN only — and there is a ceiling on how much any one source may hand over for a single query. Federated queries are a plan feature; the federated queries page carries the current source and size limits.

Put SQLite where the work happens

Install the agent, point it at your database, and pick a destination.

Start free All connectors

Read-only Outbound only Credentials stay on the agent