Anyquery: A SQLite-Based Query Engine That Puts 60+ Apps Behind One SQL Interface

The problem Anyquery solves is query surface sprawl, not storage

Most teams do not lack data. They lack one place to ask a question across it. A CSV sits next to a SQLite file, a Notion workspace holds the roadmap, GitHub holds the issues, and each of those needs a different client, a different export step, or a different API wrapper. Anyquery's answer is to keep SQLite as the storage and execution engine and treat everything else as a table you can join against. The README describes it as a SQL query engine that runs queries on files, databases and apps, built on top of SQLite and extended through plugins. That framing matters: this is not a new database, and it is not an ETL tool. It is an interface layer. The audience is engineers and analysts who already write SQL and would rather write one SELECT than three scripts, plus LLM users who want a tool-calling client to reach the same data. The README also positions it as a MySQL server, which means the same query engine can sit behind a client like TablePlus or Metabase. That combination, one engine reachable from a shell, from an LLM, and from a MySQL wire protocol, is the actual product.

SQLite plus plugins plus virtual tables is the whole architecture

The mechanism is stated plainly in the README: Anyquery is built on SQLite and uses plugins to extend its functionality. SQLite's virtual table interface is what makes a remote API look like a local table, and the Go install command confirms the build tags used for that path: vtable, fts5, sqlite_json and sqlite_math_functions. The vtable tag is the one that matters here, because without it the plugin surface would not exist. Data flow is therefore: a query arrives from the shell, an LLM client over MCP, or a MySQL client over the server; SQLite plans it; a plugin-backed virtual table fetches rows from the underlying source; SQLite handles the joins, filtering and aggregation. Two consequences follow from that design. First, pushdown depends on the plugin. A plugin that cannot translate a WHERE clause will hand rows back to SQLite and let it filter, which is fine for a small Notion database and painful for a large API. Second, joins across a local Parquet file and a SaaS API happen inside one process, so the cost profile of a query is set by the slowest remote source, not by SQLite. The README does not document per-plugin pushdown behaviour, so that is something to check per integration rather than assume.

Installing Anyquery and starting the MCP server

Installation is deliberately broad. On macOS and Linux the quick path is curl -fsSL https://anyquery.dev/install.sh | sh, which the README says downloads the right binary, verifies its checksum and adds it to PATH without sudo. Version and location are controlled by ANYQUERY_VERSION and ANYQUERY_INSTALL_DIR, and updating means re-running the same command. Package managers are covered too: brew install anyquery, an APT repository, a YUM/DNF repository, Scoop, Winget and Chocolatey. Building from source needs Go 1.26 or newer and a C compiler, because the README states Anyquery relies on cgo through go-sqlite3. The build command is CGO_ENABLED=1 go install -tags "vtable fts5 sqlite_json sqlite_math_functions" github.com/julien040/anyquery@main. Once installed, typing anyquery opens the shell. For LLM work, the README gives two MCP modes: anyquery mcp --stdio, intended to be started by the LLM client, and anyquery mcp --host 127.0.0.1 --port 8070 for an HTTP and SSE tunnel. For clients that use function calling rather than MCP, anyquery gpt prints an ID to paste into the client. The MySQL path is anyquery server, followed by a normal client connection such as mysql -u root -h 127.0.0.1 -P 8070.

Three security releases in three months is the signal to read before deploying

The release history is short and unusually candid. Version 0.4.5 is titled Security fixes, 0.4.6 is titled Security fix again, and 0.5.0 is titled Sandbox strengthening. Three consecutive releases with security in the title, within roughly two months, tells you the project is actively finding and closing holes in how plugins and queries are isolated. That is a good sign for responsiveness and a caution sign for deployment. Anyquery loads plugins and SQLite extensions, and the README notes it can load any SQLite extension. A query engine that runs plugin code and accepts SQL from an LLM client is a meaningful attack surface. The 0.5.0 sandbox work is the project's own acknowledgement of that. The practical implication: if you expose the MCP server or the MySQL server beyond localhost, you are exposing a component whose isolation model was being reworked as recently as the 0.5.0 release. The README does not describe the sandbox boundaries, so treat them as undocumented and verify them against the source before putting this anywhere reachable.

Where Anyquery is the wrong tool

The first wrong use is as a shared database for untrusted users. Anyquery is SQLite underneath, and the MySQL server is a compatibility layer over it, not a multi-writer server with per-user permissions and connection isolation. If your requirement is concurrent writes from many clients, row-level security, or replication, this is the wrong layer. The second wrong use is as a high-volume ETL engine. Because remote access goes through plugins, and the README does not document pushdown guarantees, a query that joins several API-backed tables can end up pulling far more rows than the final result contains. For nightly bulk movement of millions of records, a purpose-built pipeline will be more predictable. The third wrong use is treating integration count as coverage. The README links to a registry and the badges report a plugin count, but a registry entry does not tell you whether a plugin tracks API changes, handles pagination, or supports the fields you need. Check the specific integration page for the specific tool before committing.

How it differs from DuckDB and from a hand-written script

The closest conceptual neighbour is DuckDB, and the difference is in what each treats as the centre of gravity. DuckDB is an analytical engine built for fast local queries over columnar files and in-process data, and it has its own extension mechanism. Anyquery is SQLite plus a plugin registry aimed at live SaaS APIs, and its distinctive move is the set of access paths around the engine: an MCP server for LLM clients, a function-calling mode via anyquery gpt, and a MySQL wire protocol server for existing BI clients. If your problem is scanning Parquet files fast, DuckDB is the more direct answer. If your problem is asking one question that spans a Notion database, a local CSV and a GitHub repository, and then letting an LLM client ask the same question, Anyquery is addressing that specific shape. The other alternative is the obvious one: a script per source. That gives you total control over pagination, retries and rate limits, and it costs you the ability to join across sources in one statement. Anyquery's bet is that the join is worth more than the control, which holds when sources are small and read-mostly and breaks when they are not.

Maintenance cost and the licence question you have to resolve yourself

The maintenance story has two parts. Upgrades are cheap by design: the install script is re-run to update, and package manager installs follow the normal channel, so there is no migration procedure documented for the binary itself. The expensive part is plugins. Each integration is a separate moving piece that depends on a third-party API, and when that API changes the plugin is what breaks, not the engine. Budget for that by counting how many distinct integrations a critical query touches. The licence is the other unresolved item. The repository metadata reports NOASSERTION, which means the licence could not be automatically classified from the repository contents. That is not the same as permissive, and it is not the same as copyleft. It means the classifier did not find a match it trusted. Before shipping Anyquery inside a product, read the LICENSE file in the repository and the licence of every plugin you load, since plugins are separate artifacts and may carry different terms. This is a factual gap to close, not a legal opinion.

Editorial conclusion

Adopt Anyquery if you already think in SQL and want one query surface across local files, SQLite databases and SaaS APIs, or if you want an LLM client to reach that data through the MCP server started with anyquery mcp --stdio. Do not adopt it as a shared multi-tenant database for untrusted users, and do not assume the NOASSERTION licence label on the repository is the same as a permissive one. Verify two things first: the exact licence text shipped with the source, and whether the plugin you need is maintained, since the registry count is not a maintenance signal.

Official sources

1. Issues
2. julien040/anyquery on GitHub
3. Project website
4. README
5. Releases