Skip to main content

StackQL vs CloudQuery

CloudQuery is an open-source ELT framework for cloud assets: source plugins extract resource data from providers and load it into a destination database on a schedule, where you query the snapshots with that database's SQL. StackQL inverts the architecture: SQL is executed directly against the provider APIs at query time, with no sync step and no stored copy - and the same engine can mutate resources, not just read them.

When to use which​

Use CloudQuery when:

  • You need history: point-in-time snapshots retained across syncs for trend analysis, forensics, or compliance evidence.
  • You want asset data co-located with other warehouse data for joins in an existing BI/analytics stack (BigQuery, Snowflake, Postgres).
  • Query latency matters more than freshness - querying a local database is faster than fanning out API calls.

Use StackQL when:

  • You need current state: security checks, drift detection, operational queries, and any decision an automation or AI agent will act on immediately.
  • You do not want to operate a sync pipeline and a destination database to answer questions.
  • You need write operations - creating, updating, or deleting resources - in the same tool and language as the queries.
  • Agents are the consumer: StackQL's MCP server exposes discovery, validation, and gated execution directly; a CloudQuery destination database knows nothing about the provider API surface.

The two are complementary at scale: StackQL for live interrogation and action, CloudQuery (or StackQL results materialized on a schedule) for longitudinal storage.

Architectural comparison​

DimensionCloudQueryStackQL
ModelExtract-load, query the copyQuery the source live
FreshnessAs of last syncAs of query execution
HistoryNative (retained snapshots)Not retained (materialize manually)
Infrastructure requiredSync scheduler + destination databaseSingle binary
Writes to cloudNoINSERT / UPDATE / DELETE / EXEC
Provider definitionGo source pluginsDeclarative extended-OpenAPI specs
Query dialectDestination database's SQLStackQL SQL (Postgres-compatible wire in server mode)
Agent interfaceNone (query the destination DB)Built-in MCP server with safety modes

Example​

The freshness difference in one query - this StackQL statement reflects instances launched seconds ago, which a sync-based copy will not contain until the next sync completes:

SELECT instance_id, instance_type, launch_time
FROM aws.ec2.instances
WHERE region = 'us-east-1';

For longitudinal needs, the equivalent StackQL pattern is scheduling this query (via cron, CI, or pystackql) and appending results to your own store - the same outcome as ELT, but the live query path remains available for time-sensitive questions.