Skip to main content

What is StackQL?

StackQL is an open-source query language and runtime that exposes cloud and SaaS provider APIs as relational tables, queryable with standard SQL. It treats every cloud resource - virtual machines, storage buckets, IAM policies, GitHub repositories, Snowflake warehouses - as a row in a table, and every API operation as a SELECT, INSERT, UPDATE, or DELETE.

How it works​

A typical infrastructure tool reads cloud state into a local file (Terraform's state file), generates a plan, and applies it. StackQL skips the state file entirely. When you run a query, StackQL issues live API calls to the relevant provider, normalizes the response shape, and returns the result as rows. Nothing is cached between invocations unless the user asks for it.

The interface is SQL because SQL is a stable, well-understood query language with mature tooling - clients, drivers, BI integrations, AI agent toolkits - that all "just work" against StackQL. StackQL implements the PostgreSQL wire protocol in server mode, which means anything that can talk to Postgres (psql, DBeaver, Tableau, Power BI, pandas, LangChain SQL agents, an MCP server) can talk to StackQL.

Example​

List all S3 buckets across an AWS account with public access enabled:

SELECT
  name,
  region,
  policy_status
FROM aws.s3.buckets
WHERE policy_status::json ->> 'IsPublic' = 'true';

That query runs against the live AWS S3 API. There is no state file to refresh, no cached snapshot to invalidate, and no provider-specific SDK to learn. The same shape works for any provider - swap aws.s3.buckets for github.repos.repos or azure.compute.virtual_machines and the query model is identical.

Why it exists​

StackQL was built on the premise that cloud infrastructure should be a queryable surface, not a static artifact. The state-file model that dominated infrastructure-as-code for the last decade was designed for human-driven, change-controlled workflows: write code, plan, review, apply. That model strains under two pressures:

  1. Multi-cloud reality. Every major organization runs workloads across multiple providers. State files are per-provider, per-tool, per-team. Asking "what do we run in production?" across AWS, Azure, GitHub, and Snowflake is a manual aggregation exercise.
  2. AI agents. Agents need live, structured access to infrastructure state to reason about it. A state file is the wrong primitive - it is stale by the second it is written, and its format is tool-specific. A SQL interface against live APIs is the right primitive: agents know SQL, the schema is stable, and the data is always current.

StackQL exists to make cloud infrastructure as queryable as a database, across providers, for both human operators and AI agents.

Other pages in this section that will link from here once written:

  • What is Queryable Infrastructure? - the broader category StackQL belongs to
  • What is SQL for APIs? - the design pattern StackQL implements
  • Control Plane vs Data Plane - how StackQL unifies both
  • StackQL vs Terraform - comparison with the dominant IaC tool
  • StackQL vs Steampipe - comparison with the closest peer