# Anyquery: One SQL Interface for 60+ Tools, Files and MCP Clients > Anyquery is a Go SQLite-based query engine that exposes files, databases and SaaS apps as SQL tables, then re-serves them to MySQL clients and LLM agents over MCP. It is for engineers who want one query surface across many sources, and it asks them to accept a plugin registry and a cgo build in return. **julien040/anyquery** — One SQL interface for 60+ tools (e.g., GitHub, Notion, Airtable). Plug into any LLM through MCP. - Repository: https://github.com/julien040/anyquery - Website: https://anyquery.dev - Stars: 1,778 · Forks: 137 - Language: Go - License: NOASSERTION - Published: 2026-09-10 · Updated: 2026-09-10 · Language: en - Canonical page: https://hysenlabs.com/projects/julien040-anyquery ## The problem Anyquery picks: too many sources, one query language Most teams end up with the same shape of problem. Salesforce holds the pipeline, Notion holds the specs, GitHub holds the issues, and a folder of CSV and Parquet files holds whatever the analytics team exported last week. Answering one question across those sources means writing a connector per pair, or exporting everything into a warehouse first. Anyquery takes a different position: keep the sources where they are, and make each one look like a SQLite table. The README describes it as "a SQL query engine that allows you to run SQL queries on pretty much anything," covering files, databases and apps such as Apple Notes, Notion, Chrome and Todoist. The intended user is not a data engineer building a warehouse. It is an engineer or analyst who already knows SQL and wants to join a Notion database to a local Parquet file without standing up infrastructure. The second audience is the LLM tooling crowd. Because Anyquery can expose its tables through the Model Context Protocol, an agent gets a query language instead of a pile of bespoke function calls, which is a meaningfully narrower interface to reason about. ## SQLite underneath, plugins on top, three front ends The architecture is stated plainly in the README: Anyquery is built on top of SQLite and uses plugins to extend its functionality. That choice explains most of the behaviour. SQL parsing, joins, aggregation and the shell come from SQLite. Anything that is not a file or a local database comes from a plugin, which is a separate process the host loads. The go.mod file lists hashicorp/go-plugin, the same library HashiCorp uses for out-of-process plugins, alongside a fork of the SQLite driver, github.com/julien040/go-sqlite3-anyquery. Plugins are therefore not in-process shared libraries by default; they are subprocesses talking over a plugin protocol, which is why a crashing integration does not necessarily take the shell down with it. On top of that engine sit three front ends. The interactive shell, opened by typing anyquery with no arguments, is the first. The MySQL server, started with anyquery server, is the second, and it lets MySQL-compatible clients connect as if Anyquery were a MySQL instance. The MCP server is the third, and it is the one the project leads with in its description. The data flow is the same in all three cases: a client sends SQL, the engine plans it, plugins fetch rows from the remote source, and results come back as rows. There is no separate storage layer to keep in sync, which is the main appeal and also the main limitation, since every query pays the latency of the source. ## Installing Anyquery and running a first query The documentation lists Homebrew, APT, YUM/DNF, Scoop, Winget, Chocolatey and the AUR, plus a binary download from the releases page. The quickest path on macOS and Linux is the install script, which the README says downloads the right binary for your platform, verifies its checksum and adds it to your PATH without sudo: ```bash curl -fsSL https://anyquery.dev/install.sh | sh ``` If you prefer a package manager, Homebrew is a single command, and the APT path adds a repository first. Note that the APT repository is configured with trust=yes and the YUM repository with gpgcheck=0, so neither verifies package signatures. That is a deliberate trade-off by the maintainer, and it is worth knowing before you put it on a build machine. ```bash brew install anyquery ``` Once installed, running anyquery with no arguments opens the shell. From there you can query a local file directly, since file querying is one of the documented capabilities. The README shows the shell as the place to try queries, and the documentation at anyquery.dev/docs/usage/running-queries covers the syntax in detail. ```bash anyquery ``` To point an LLM client at it, the README gives two forms of the MCP command: stdio for a client that spawns the process itself, and an HTTP and SSE tunnel on a host and port for clients that connect over the network. ```bash anyquery mcp --stdio anyquery mcp --host 127.0.0.1 --port 8070 ``` For clients that support function calling rather than MCP, anyquery gpt prints an ID that you paste into the client. The README shows ChatGPT and TypingMind as examples. ```bash anyquery gpt ``` Finally, the MySQL server mode. The README starts it in the background and connects with the standard mysql client on port 8070, which is the same port the MCP HTTP mode uses, so do not run both on one machine without changing one of them. ```bash anyquery server & mysql -u root -h 127.0.0.1 -P 8070 ``` ## Where Anyquery stops being the right tool The plugin model is the first constraint. Anyquery itself is a query engine; the value is in the integrations, and those come from a registry. The README links to anyquery.dev/integrations for the official registry and notes that you can create your own plugins or load any SQLite extension. That means the quality, rate-limit handling and authentication model of each integration is the responsibility of whoever wrote it, and the repository does not present a review process for registry entries. If your use case depends on a source that no one has written a plugin for, Anyquery gives you a plugin SDK rather than a connector. The second constraint is that Anyquery is a query layer, not a cache. Every query against a remote app hits that app's API. There is no materialisation step described in the README, so a join between a large Notion database and a local file will make as many API calls as the planner decides it needs. For a dashboard that refreshes every few seconds, that is the wrong shape; a warehouse with a scheduled sync is the right one. The third is the build. Installing from source requires Go 1.26 or later and CGO_ENABLED=1, and the README states that Anyquery relies on cgo through go-sqlite3, so a C compiler must be on the PATH. If your environment forbids cgo or you need a static binary for a minimal container, the prebuilt packages are the only route. ```bash CGO_ENABLED=1 go install -tags "vtable fts5 sqlite_json sqlite_math_functions" github.com/julien040/anyquery@main ``` The fourth is operational: the MySQL server mode is a compatibility layer, not MySQL. Anything that depends on MySQL-specific behaviour beyond ordinary queries may not survive the translation, and the README does not document a compatibility matrix. ## How this differs from Steampipe and from a warehouse The closest comparison is Steampipe, which also exposes APIs as SQL tables, but the two make opposite bets on the engine. Steampipe runs on PostgreSQL and its foreign data wrappers, so you get Postgres semantics, Postgres extensions and a Postgres wire protocol. Anyquery runs on SQLite, which means a much smaller binary, no server to operate in shell mode, and SQLite's dialect rather than Postgres's. If your team already writes Postgres-flavoured SQL with window functions and CTEs, Steampipe will feel familiar; if you want a single binary you can drop on a laptop and query a Parquet file with, Anyquery is the lighter answer. The second comparison is against the warehouse pattern. A warehouse copies data on a schedule and then queries the copy, which is fast and stale. Anyquery queries the source, which is fresh and slow. Those are not competing implementations of the same thing; they are different answers to the question of where the data lives. Choosing Anyquery means accepting that your query latency is your API latency. The third difference is the LLM angle. Most SQL-over-APIs tools predate MCP and expose a CLI or a Postgres endpoint. Anyquery ships an MCP server as a first-class command, and the go.mod dependency on mark3labs/mcp-go confirms it is built in rather than bolted on. If your goal is to give an agent access to business data, that is the shortest path in this category. ## Maintenance, licensing and upgrade cost The last push to the default branch was on 2026-08-16, and the most recent release is 0.5.0 from 2026-08-05, labelled "Sandbox strengthening." Two earlier releases in the same year, 0.4.5 and 0.4.6, are labelled security fixes, which tells you the project has had at least two security-driven patch cycles in 2026. The version number is still 0.x, so minor releases can change behaviour, and the release titles suggest the maintainer treats security work as a named category rather than folding it into feature releases. Budget for reading release notes before upgrading, particularly around the plugin sandbox, since that is what 0.5.0 changed. On licensing, the repository metadata reports NOASSERTION, which means the automated classifier could not match the LICENSE.md file to a known SPDX identifier. The file exists at the repository root, so the terms are stated there, but the licence is not one of the common templates. If you are planning to embed Anyquery in a product, read LICENSE.md directly rather than assuming MIT or Apache-2.0 from the Go ecosystem. Nothing here is legal advice; the point is that the licence is the one thing you cannot infer from the language or the topic list. The upgrade surface is the plugin protocol. Because plugins are separate processes loaded by the host, a host upgrade can break a plugin built against an older protocol, and the README does not describe a compatibility guarantee between host versions and registry plugins. Pin your host version in CI and test your specific plugins after each bump. ## The MCP server is the part that will decide adoption Anyquery's own description puts the LLM integration first: "Plug into any LLM through MCP." That is the bet. The SQL engine is not novel, and the plugin registry is not novel, but shipping an MCP server that turns sixty integrations into a single tool an agent can call is a different proposition from shipping sixty function-calling wrappers. The agent does not need to know that Notion and GitHub are different systems; it needs to know how to write a SELECT. That also concentrates the risk. An LLM with SQL access to your Notion workspace, your GitHub issues and your local files has read access to all of it, and the README does not describe a permission model beyond what the underlying plugins authenticate with. The 0.5.0 release title, "Sandbox strengthening," suggests the maintainer is aware of this, but the README does not document what the sandbox actually restricts. Before pointing an agent at production data, check the SECURITY.md file at the repository root and the release notes for 0.5.0 to see what changed. That is the specific thing to verify, and it is more important than any benchmark. ## Conclusion Adopt Anyquery if you already think in SQL and want one place to join Notion, GitHub and local Parquet without writing a connector per source, or if you want an MCP server that gives an LLM read access to those tables with a query language as the boundary. Do not adopt it if you need a supported, versioned API with an SLA, if you cannot run cgo builds, or if you expect the plugin registry to be audited by anyone but its authors. Verify first that the plugins you need exist in the registry at anyquery.dev/integrations, that your MCP client speaks the stdio or HTTP/SSE transport shown in the README, and that your MySQL client tolerates the server started by anyquery server. ## FAQ ### What is Anyquery? Anyquery is a SQL query engine built on SQLite that runs queries against files, databases and apps such as Notion and GitHub through plugins. It can also act as a MySQL server and connect to LLM clients over the Model Context Protocol. ### How do I install Anyquery on macOS or Linux? The README gives a quick install script that downloads the correct binary, verifies its checksum and adds it to your PATH without sudo. Homebrew, APT, YUM/DNF, Scoop, Winget, Chocolatey and the AUR are also supported. ### How does Anyquery connect to an LLM? It runs an MCP server, started with anyquery mcp --stdio for clients that spawn the process or anyquery mcp --host 127.0.0.1 --port 8070 for an HTTP and SSE tunnel. Clients that support function calling instead of MCP can use the ID printed by anyquery gpt. ### Can I query Anyquery from a MySQL client? Yes. Running anyquery server starts a MySQL-compatible server, and the README connects to it with mysql -u root -h 127.0.0.1 -P 8070. The README does not document which MySQL features are supported beyond ordinary queries. ### What licence is Anyquery released under? The repository metadata reports NOASSERTION, so the licence could not be matched to a standard SPDX identifier. The terms are in the LICENSE.md file at the repository root, which should be read directly before embedding the project in a product. ## Sources - [Issues](https://github.com/julien040/anyquery/issues) - [julien040/anyquery on GitHub](https://github.com/julien040/anyquery) - [Project website](https://anyquery.dev) - [README](https://github.com/julien040/anyquery/blob/main/README.md) - [Releases](https://github.com/julien040/anyquery/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/julien040-anyquery