简体中文
EnglishWhat Is CloudQuery and What Does It Do?
Updated
CloudQuery is an open-source, self-hosted tool that syncs data from 80+ cloud and SaaS sources into a database you already operate, so you can inspect, govern, and automate your cloud estate using standard SQL. It fits teams that are tired of maintaining a separate exporter or script for every provider and want one config-as-code pipeline instead. Because it is self-hosted, your credentials and synced data stay inside your own network unless you choose otherwise.
The core idea: one sync, your database, standard SQL
Most cloud and SaaS platforms each expose their own API, their own query model, and their own dashboard filters. CloudQuery replaces that fragmentation with a single pipeline:
- Sources are the cloud providers and SaaS apps you point at (AWS, GCP, Azure, GitHub, Okta, and 80+ others).
- Destination is the database you already run — Postgres, BigQuery, Snowflake, or S3.
- Query layer is standard SQL, with no proprietary language to learn.
The result is that data from many providers lands in one relational shape, and you query all of it the same way.
How it works: install, define, sync
CloudQuery describes a three-step path from install to first sync.
1. Install CloudQuery
It ships as a single binary for Linux, macOS, or Windows. Documented install options include:
- macOS (Homebrew):
brew install cloudquery/tap/cloudquery - Linux, CI, or agents:
curl -fsSL https://cloudquery.io/install.sh | sh - Windows or Docker: other install options are listed on the site
2. Define sources in YAML
You point at the cloud providers and SaaS apps you want, plus the destination database you already operate. Every sync is defined in version-controlled YAML, which means it can be reviewed in pull requests like any other code change.
3. Run the sync
Run it once, or on a schedule inside your pipeline. Data lands in Postgres, BigQuery, Snowflake, or S3.
The expected result after step 3 is that your selected sources are queryable with SQL in your own database, without you writing per-provider export logic.
What problem it replaces
CloudQuery frames the alternative as "the old way": gluing together a different exporter for every provider. The comparison it draws:
| Dimension | DIY scripts & exporters | With CloudQuery |
|---|---|---|
| Source coverage | A separate script or exporter per source | One tool syncs 80+ sources |
| Querying | Each tool has its own query language or dashboard filters | Standard SQL everywhere |
| Data control | Credentials and data spread across tools you don't fully control | Self-hosted; data stays in your network unless you choose |
| Versioning & review | No version history or single source of truth | YAML in version control, reviewed in PRs |
| New sources | Start from scratch | Build with the SDK if a source is missing |
| Speed at scale | Scans slow down or time out as accounts grow | Incremental sync keeps scans across hundreds of accounts fast |
The practical takeaway: if you are maintaining one-off exporters per provider and want a single, reviewable, SQL-queryable pipeline, that is the gap CloudQuery targets.
Where the "AI scale" positioning comes in
CloudQuery describes itself as an access layer for cloud infrastructure, and the same synced data is positioned as a context layer for AI agents. Two specifics from the site:
- MCP-native: you can point Claude, Copilot, or an internal agent at the CloudQuery MCP server (in PostgreSQL or Snowflake Mode), backed by your synced data, and it queries your cloud estate directly — no bespoke integration to build or maintain.
- One normalized schema: AWS, GCP, Azure, GitHub, Okta, and 80+ other sources land in the same relational shape, so an agent reasons over a consistent structure instead of 80 raw APIs.
If your goal is simply SQL access to cloud data, the MCP angle is optional. If you are building agents that need live infrastructure context, it is the relevant part.
When CloudQuery is a good fit — and when it isn't
Good fit if you:
- Want cloud and SaaS data in a database you already run (Postgres, BigQuery, Snowflake, S3).
- Prefer config-as-code YAML that can be versioned and reviewed in pull requests.
- Need self-hosting so credentials and data stay in your network.
- Are scaling across many accounts and need incremental sync to stay fast.
- Want to expose infrastructure data to AI agents through MCP.
Probably not the right tool if you:
- Want a fully managed SaaS with no self-hosting.
- Only need a single provider and are happy with that provider's native console.
- Don't have a destination database you operate or want to operate.
Pricing and getting started
The site lists a Pricing page and a "Free" heading, but the provided material does not include specific plan details, limits, or payment terms. Check the pricing page directly before assuming what is included at no cost.
To evaluate it, the lowest-friction path is the documented one: install the binary, write a YAML config pointing at one source and one destination database, run a single sync, then query the result in SQL. That gives you a concrete read on coverage, schema shape, and speed before committing to a broader rollout.