Skip to main content

StackQL vs Steampipe

Steampipe and StackQL implement the same core idea - cloud and SaaS APIs exposed as SQL tables - with one decisive difference: Steampipe is read-only, while StackQL also writes. Steampipe embeds PostgreSQL and maps APIs through foreign data wrappers fed by Go plugins; StackQL implements its own SQL engine over declarative, OpenAPI-derived provider specs, and maps the full verb set: SELECT, INSERT, UPDATE, DELETE, and EXEC for lifecycle actions.

When to use which​

Use Steampipe when:

  • Your use case is purely read: inventory, compliance dashboards, security posture.
  • You want its mature ecosystem of compliance mods (CIS, SOC 2, and similar prebuilt benchmark packs).
  • You are already invested in PostgreSQL FDW-based tooling and the Turbot ecosystem around it.

Use StackQL when:

  • You need reads and writes in one tool - query a misconfiguration, then fix it with an UPDATE in the same session.
  • You are building for AI agents: StackQL ships a built-in MCP server with discovery tools, query validation, gated mutation modes, and an audit log.
  • You want provider coverage driven by API specifications rather than plugin development, including data plane and lifecycle operations.
  • You want a deterministic, dependency-light single binary that also speaks the PostgreSQL wire protocol in server mode.

Both are open source, both run locally or in pipelines, and for read-only inventory queries they are genuinely interchangeable in capability; the choice there comes down to schema preference and ecosystem.

Architectural comparison​

DimensionSteampipeStackQL
SQL verbsSELECT onlySELECT, INSERT, UPDATE, REPLACE, DELETE, EXEC
EngineEmbedded PostgreSQL + foreign data wrappersNative SQL engine (embedded SQLite or PostgreSQL backend)
Provider definitionCompiled Go pluginsDeclarative extended-OpenAPI specs in an open registry
Plane coverageControl plane readsControl and data plane, reads and writes
AI agent interfaceGeneric Postgres connectivityBuilt-in MCP server with safety modes and audit logging
Server modePostgres wire (steampipe service)Postgres wire (stackql srv) plus MCP (stackql mcp)
Compliance contentExtensive mod libraryQuery-based; no packaged benchmark library

The provider-definition difference compounds over time: a Steampipe table exists when someone writes plugin code for it, while a StackQL table exists when the API operation is described in the provider spec. The write capability difference is categorical: closed-loop workflows - detect, decide, remediate - fit in one StackQL session, whereas Steampipe hands off remediation to another tool.

Example​

Identical intent in both tools - but in StackQL, the follow-up remediation stays in the same language. Query EC2 instances:

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

A remediation in StackQL is then a DELETE or EXEC (for example, terminating or stopping an instance) against the same table, subject to the credential's permissions and - when running as an MCP server - the configured safety mode.