Steampipe: query cloud APIs with SQL and no database

The problem Steampipe solves for cloud and SaaS engineers

Most teams that want to ask a question across AWS, GitHub and Kubernetes end up writing a script per API, handling pagination and auth in each one, then dumping the results somewhere before they can join them. Steampipe takes the other route: it exposes APIs as database tables, so the join happens in SQL and the API client code is somebody else's problem. The README states it is "the zero-ETL way" to query APIs and services, and the plugin hub lists AWS, Azure, GCP, Kubernetes, GitHub, Microsoft 365 and Salesforce among the targets.

The audience is narrower than the tagline suggests. This is for engineers who are already comfortable writing SQL and who want to run that SQL against live infrastructure, either interactively or inside a CI/CD pipeline. The README notes the binary is a single file that can be used locally or deployed in pipelines. If your team has no SQL habit, the value proposition is weaker, because the whole interface is a query language rather than a dashboard or an SDK.

How plugins turn an API into tables

The architecture is a core binary plus plugins. The README describes plugins as mapping APIs to database tables, and says the community suite covers more than 2000 tables, each documented with copy/paste/run examples. The core binary carries a Postgres instance, and the CLI translates queries against those tables into API calls. The repository layout supports this: the Go module is github.com/turbot/steampipe/v2, with cmd/ and pkg/ at the top level and a Makefile that builds a plugin manager service and a dashboard UI before the main binary.

Two details in the dependency list say something about the design. github.com/hashicorp/go-plugin appears in go.mod, which is the standard HashiCorp plugin transport, so plugins run as separate processes rather than being linked into the binary. github.com/jackc/pgx/v5 is the Postgres driver. That combination is the reason the README can claim concurrency across many data sources: each plugin process can fetch in parallel while the core holds the SQL session.

The same design explains the distribution list. Because the translation layer is separate from the query engine, the README says the same plugins are available as Postgres foreign data wrappers, as SQLite extensions, and as standalone export binaries that need no database at all. Turbot Pipes is the hosted option. That is a wider footprint than most CLI tools attempt, and it follows directly from keeping the API mapping out of the core.

Installing Steampipe and running a first query

The README points to the downloads page and gives two install paths. On macOS the Homebrew tap is the short one:

brew install turbot/tap/steampipe

On Linux or Windows under WSL2, the README gives an install script invoked through sh:

sudo /bin/sh -c "$(curl -fsSL https://steampipe.io/install/steampipe.sh)"

Both commands are copied from the README. Neither is verified here, so read the script before piping it into a shell if your environment requires that.

Plugins are installed by name. The README uses Hacker News as the example, which is a sensible first target because it needs no cloud credentials:

steampipe plugin install hackernews

Then start the interactive query shell and select from the table the plugin creates:

steampipe query
> select * from hackernews_new limit 10

The prompt shown in the README is the > character inside steampipe query, and the table name is hackernews_new. If that returns rows, the core binary, the plugin process and the Postgres layer are all working. For a service that needs credentials, the plugin install step is the same and the difference is configuration rather than command syntax; the README defers that to the plugin pages on the hub.

There is also a self-referential plugin that is useful for confirming what a plugin exposes. The README's development section shows installing it and inspecting it:

steampipe plugin install steampipe

steampipe query
> .inspect steampipe

That prints the table list, which in the README example contains steampipe_registry_plugin and steampipe_registry_plugin_version. The .inspect command is the fastest way to find out whether a plugin actually ships the table you were hoping for.

Where Steampipe is the wrong tool

The zero-ETL framing is honest about what this is not: a data warehouse. Because queries hit APIs in real time, a query that looks cheap in SQL can turn into many paginated HTTP requests. The README does not document a caching layer or a rate-limit budget, so the cost of a wide query is something you discover from the API side, not from the tool. If your question is "what did this look like last quarter", Steampipe is not the answer, because there is no history unless you export it yourself.

Credentials are the second boundary. A plugin needs access to the target service, and giving it broad read access to a cloud account is a real decision, not a configuration detail. The README does not describe a permission model beyond whatever the underlying API enforces.

The third case is distribution. The README states the repository is under AGPL 3.0, and separately says Steampipe is a product produced from this open source software exclusively by Turbot HQ, Inc, distributed under commercial terms, with others allowed to make their own distribution but not to use Turbot trademarks or cloud services. If you intend to embed Steampipe in something you ship, that combination of licence and trademark terms is worth reading before you build on it. This is not legal advice, and the Open Source FAQ is the place to check.

How Steampipe differs from Steampipe Postgres FDW and SQLite extensions

The most useful alternative is not another vendor, it is the same project in a different shape. The README lists three distributions besides the CLI: native Postgres foreign data wrappers, SQLite extensions, and standalone export binaries. The FDW path puts the API tables inside a Postgres instance you already run, so the plugin data can be joined against your own tables in one query. The SQLite path does the same for SQLite virtual tables, which matters if your tooling is embedded rather than server-based. The export binaries skip the database entirely and just pull data out of an API.

The difference in approach is where the query engine lives. The CLI ships its own Postgres and owns the session. The FDW and SQLite variants hand the API tables to a database you already operate, which means you inherit that database's backup, access control and connection pooling, and you also inherit its operational burden. If you already run Postgres and want cloud tables alongside application tables, the FDW is the closer fit than the CLI. If you want a one-off dump, the export binaries avoid starting a database at all. Choosing between them is a deployment question, not a feature question.

Maintenance, releases and the AGPL-3.0 question

The repository is not archived and the last push was on 2026-09-17. Releases are frequent: v2.4.7 on 2026-09-16, v2.4.6 on 2026-09-09, v2.4.5 on 2026-08-10. The default branch is develop, which is where the code lives between releases, so building from source gives you something ahead of the tagged versions. The Makefile builds to /usr/local/bin by default and accepts an OUTPUT_DIR override, and it stamps the version as 0.0.0-dev-<branch>.<timestamp> for local builds, so a self-built binary will not report a release version.

Upgrade cost is mostly plugin cost. The core binary updates on its own cadence, but each plugin has its own version history on the hub, and a plugin update can change table schemas. The README does not document a compatibility guarantee between core and plugin versions, so pinning matters if you run Steampipe in CI. The go.mod requires go 1.26.7, which is a recent toolchain and worth checking against your build environment before you attempt a source build.

On licensing, the AGPL 3.0 is a network copyleft licence. The README's own framing of the commercial terms and trademark restrictions is the material to read, and it is explicit that others may distribute the software but not under Turbot's trademarks or cloud services. Contributors must sign a Contributor License Agreement as part of their first pull request.

Editorial conclusion

Adopt Steampipe if you already think in SQL and want live API data without building an ETL pipeline first; the plugin install plus steampipe query loop is short enough to evaluate in an afternoon. Do not adopt it if you need long-term historical storage or a guarantee that a query will not fan out into many throttled API calls, because the tool queries APIs in real time and the README does not document a caching or rate-limit layer. Before committing, verify that the plugin for your service exposes the tables you need, check the AGPL-3.0 obligations against how you plan to distribute anything built on the binary, and confirm the current release cadence on the develop branch.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. turbot/steampipe on GitHub