StackQL: SQL as the control plane for cloud and SaaS APIs

The problem StackQL targets: one query language over many provider APIs

Anyone who operates across more than one cloud or SaaS vendor spends a lot of time in per-vendor tooling. Google Cloud, AWS, Azure, Okta and GitHub each ship their own CLI, their own authentication flow, their own output format and their own pagination rules. Writing a report that answers a question spanning two of them usually means writing a script that shells out to two CLIs and joins the results in memory. StackQL's premise is that this work is fundamentally a query problem, and that SQL is a reasonable interface for it. The README describes the project as allowing you to "create, modify and query the state of services and resources across different local and remote interfaces, using SQL semantics", with cloud and SaaS providers named explicitly as the canonical case. The intended audience is therefore platform, security and cloud operations engineers who are comfortable with SQL and tired of vendor-specific scripting. The topics attached to the repository (cloud-operations, cspm, identity-governance, asset-management) map onto that audience: people who need to enumerate, inspect and occasionally change resources across providers, often for compliance or inventory reasons rather than for application delivery.

How the transpilation actually works

StackQL is a Go application that parses SQL statements and rewrites them into API requests. The README is direct about the mechanism: "StackQL parses SQL statements and transpiles them into API requests to the (cloud) resource provider. The API calls are then executed and the results are returned to the user." The provider side is where the design gets specific. Provider interfaces are defined as OpenAPI extensions to each provider's own specification, and those definitions are used to generate both the SQL schema and the API client. In other words, the tables you can query are derived from an OpenAPI document, not hand-written per provider. The definitions live in the StackQL Registry, a separate repository, and the semantics of provider interaction are implemented in a library called any-sdk. That layering matters when you evaluate the tool: the SQL dialect you get for, say, Okta is a function of how faithfully the Okta OpenAPI specification has been extended and how the any-sdk mapping handles its particular pagination and parameter conventions. Nothing in the supplied material describes how joins across providers are executed, whether results are materialised locally, or what the planner does with a WHERE clause. Treat the SQL layer as a query surface over remote APIs, not as a relational engine, until the design docs say otherwise. The repository points to a local AGENTS.md and the any-sdk AGENTS.md for the details, which is where you would go to confirm that.

Client mode, server mode and the MCP server

There are three ways to reach the engine, and they suit different jobs. Client mode uses the exec or shell subcommands: exec for a single statement driven from a script or CI job, shell for an interactive session. Server mode runs as srv and speaks the Postgres wire protocol, so an ordinary Postgres client such as psycopg2 can connect and issue queries. That is an unusual choice and a useful one, because it means a BI tool or a Python notebook that already knows how to talk to Postgres can point at StackQL without a bespoke driver. The third surface is the MCP server, published as @stackql/mcp-server on npm and listed in the MCP Registry. The README frames the whole project around this: the tagline reads "The Universal Interface for the Agentic Era", and the topics include llm-tools and ai-agents. The MCP server is the concrete artefact behind that framing. For an agent, the alternative to StackQL is a set of per-provider tool definitions that must be written and maintained individually; StackQL's offer is a single query interface that spans providers. Whether that produces better agent behaviour is not something the supplied material demonstrates, and I would not assume it does without trying it.

Installing and running it

Installation is conventional for a Go CLI. The README lists a macOS package at stackql_darwin_multiarch.pkg, a Windows MSI at stackql_windows_amd64.msi, a Windows zip, and a Linux zip at stackql_linux_amd64.zip, all served from releases.stackql.io under a latest path. Docker images are published under the stackql organisation on Docker Hub, including stackql/stackql and a Jupyter demo image, stackql-jupyter-demo. For CI, there are two GitHub Actions on the marketplace: setup-stackql and stackql-exec. Once installed, the entry points are the subcommands named in the README: exec for one-shot statements, shell for interactive use, and srv for the Postgres-protocol server. The README links a variables page in the docs for authentication and templating configuration, which is where credentials for each provider are handled. I have not installed or run any of this, so I cannot describe the exact output of a first query or the shape of the shell prompt. The honest summary is that the distribution channels are broad (four platform packages, Docker, two CI actions, an npm-published MCP server) and the configuration detail lives in the docs rather than the README.

Where the model breaks down

The most important limitation is inherited from the design: your SQL surface is exactly as wide as the provider definition. If a provider's OpenAPI specification omits an operation, or if the StackQL extension for it has not been written, that operation is not reachable through SQL, no matter how the query is phrased. The Registry is a separate repository, which means coverage is a moving target that you should check before committing to the tool for a specific workload. A second limitation is the nature of the execution model. Each statement becomes one or more API calls against a remote service, so latency and rate limits are the provider's, not StackQL's, and a query that looks cheap in SQL terms can turn into a long sequence of HTTP requests. Anything resembling a multi-table join across two providers is going to be constrained by what can be pushed down to each API. The third issue is fit. StackQL is a query and operations tool, and the README's own framing ("Configuration-as-Data. Infrastructure-as-Context.") positions it alongside infrastructure tooling rather than inside it. If what you actually need is a declarative description of desired state that a controller reconciles continuously, this is the wrong shape of tool, and the fact that it can issue create and modify statements does not change that. It can change resources; it does not hold a state file or converge a plan.

How it differs from Terraform and from cloud-native query tools

The closest familiar comparison is Terraform. Terraform takes a declarative configuration, builds a dependency graph, and reconciles actual state toward the declared state, keeping a state file to know what it owns. StackQL takes an imperative SQL statement and executes it against an API immediately. There is no plan phase, no state file, and no ownership tracking in the model as described. That difference is the whole point: StackQL is better suited to asking questions (which buckets are public, which Okta users have no MFA enrolled) and to one-off or scripted changes, while Terraform is better suited to standing infrastructure that must stay in a known configuration. The second comparison is to per-provider query tools. AWS Config and Google Cloud Asset Inventory each give you a query surface, but only for their own provider and only for the resource types they index. StackQL's claim is cross-provider reach through one dialect, at the cost of being a thinner layer over each provider's own API rather than a curated inventory with its own indexing and history. If your question spans providers, that trade is worth examining; if it does not, the native tool is likely to be simpler and better supported.

Licence, releases and what maintenance looks like

StackQL is MIT licensed, which is permissive and places few obligations on how you use or redistribute it. That applies to the core application; the provider definitions in the StackQL Registry and the any-sdk library are separate repositories and you should check their licences independently rather than assuming they match. On releases, the version history shows a v0.11 line with v0.11.669 dated 2026-09-08, and earlier v0.10 releases (v0.10.605 and v0.10.601) in August 2026. The cadence is frequent, and the version numbers are in the 0.x range, which is a signal about API stability rather than about quality: interfaces can still move between minor versions. The practical consequence for an adopter is that pinning matters. Pin the StackQL binary version in CI rather than tracking latest, and pin the provider definitions you depend on, because a schema change in a provider extension can change what your queries return. The GitHub Actions (setup-stackql and stackql-exec) are the natural place to enforce that pin. There is no material here describing a long-term support policy or a deprecation process, so treat upgrade testing as your own responsibility.

Editorial conclusion

Adopt StackQL if your team already writes SQL and needs to read or act on cloud and SaaS state across providers from one client, or if you want an MCP server that gives an agent a queryable surface rather than a pile of per-provider tools. Do not adopt it as a Terraform replacement for long-lived declarative infrastructure, and do not adopt it if you need a relational engine with real joins and transactions. Verify first that the provider you need exists in the StackQL Registry and that its OpenAPI-derived schema covers the operations you care about, because the SQL surface is only as wide as the provider definition behind it.

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. stackql/stackql on GitHub