// the find
turbot/steampipe
Zero-ETL, infinite possibilities. Live query APIs, code & more with SQL. No DB required.
Steampipe lets you query live APIs and cloud services using SQL by wrapping them as Postgres foreign tables or SQLite virtual tables. It ships a bundled Postgres instance so you can point a SQL client at AWS, GitHub, Kubernetes, and 100+ other APIs without writing ETL pipelines. The target audience is DevOps and security engineers who already think in SQL and want ad-hoc queries against infrastructure.
The FDW distribution is genuinely useful — you can attach it to an existing Postgres instance and join your own tables against live API data, which beats having to export first. The plugin ecosystem is large and well-documented; each table has copy-paste examples which matters for tools like this where discoverability is half the problem. Parallel query execution across data sources is handled at the engine level, so a JOIN across AWS and GitHub doesn't serialize. The export-only binary mode is a practical addition — you get the plugin data without needing to run a database at all.
AGPL 3.0 is a real adoption barrier for anyone building internal tooling at a company with a strict open-source policy — this is likely intentional to push teams toward Turbot Pipes, but it's a gotcha worth knowing up front. Live queries mean no query planner pushdown for most predicates; a WHERE clause on a non-indexed API field often fetches the full table and filters in Go, so large datasets get expensive fast. The bundled Postgres approach means you're carrying a whole database process just to query an API — startup time and resource overhead are non-trivial in CI pipelines. Plugin development requires writing a full Go gRPC plugin, which is significantly heavier than a simple config or script-based approach.