CloudQuery is an open-source, Go-based cloud asset inventory and ELT tool, licensed under MPL-2.0, that syncs metadata from AWS, Azure, GCP, and more than 70 cloud and SaaS sources into a data warehouse so platform, security, and FinOps teams can query it with SQL.

What it is

CloudQuery is a cloud asset inventory built for platform teams. It extracts configuration and metadata from cloud infrastructure, security, and FinOps sources — AWS, Azure, and GCP among the cloud infrastructure providers, plus SaaS sources such as Wiz, Finout, and GitHub — and loads that data into a destination such as a data warehouse, where it can be unified and queried. The project is written in Go and sits in the data engineering and ELT ecosystem, alongside tools in the same space such as Airbyte, and it is composed of a CLI, a plugin system, and a plugin SDK published at github.com/cloudquery/plugin-sdk.

The concrete problem it replaces is writing scripts against poorly documented cloud APIs. Instead of hand-rolling collectors for each provider and each new data source, a team configures sources and destinations and runs a sync, receiving normalized data with rate limit handling. That normalized output is the point: it makes cloud asset data queryable with SQL and lets the same data feed a cloud asset inventory, cloud security posture management, or cloud FinOps practice without separate extraction code for each use case.

Key capabilities

• Collects cloud configuration data from all major cloud infrastructure providers, including AWS, GCP, and Azure, and unifies it into a multi-cloud asset inventory.
• Extracts from more than 70 cloud and SaaS sources, including Wiz, Finout, and GitHub, with normalization and rate limit handling.
• Loads into destinations such as data warehouses, with BigQuery appearing among the project topics.
• Makes data queryable with SQL, so unified cloud asset data can be analyzed directly rather than through bespoke API scripts.
• Uses Apache Arrow to power fast, high-volume syncs with fine-grained control.
• Runs on the user's own infrastructure, so cloud data does not touch CloudQuery's servers.
• Supports an open plugin system and a plugin SDK, letting teams extend and compose new sources and destinations in multiple languages without lock-in.
• Turns cloud data into signals by connecting with BI tools, Slack alerts, Jira ticketing, and similar downstream systems.

Who uses it and how

• Platform teams building a cloud asset inventory across AWS, GCP, and Azure, unifying configuration metadata in one warehouse.
• Security teams building CSPM, monitoring and enforcing security policies across cloud infrastructure for AWS, GCP, Azure, and other providers.
• FinOps teams collecting and unifying billing data from cloud providers to reduce cloud spend.
• Attack surface management work, reflected in the project topics, where inventory and exposure data must be joined with security findings.
• Regulated, security-sensitive, or performance-critical environments, where the requirement that cloud data never leaves the operator's own infrastructure is decisive.

Getting started

Install the CLI with brew install cloudquery/tap/cloudquery; the quickstart guide at cloudquery.io/docs/cli/getting-started covers Linux and Windows installation and a first sync.

How it compares

Among the similar tools named in this registry's facts, Airbyte is the closest reference point, since both live in the ELT and data integration space and share the data-integration framing. CloudQuery differs in focus: its plugin coverage is specialized for cloud infrastructure, security, and FinOps sources with normalization and rate limit handling, rather than general-purpose application data replication. Both are self-hosted and open, so the choice rests on whether the workload is cloud configuration and security metadata or broader application data movement.

When to use it — and when not to

Choose it when the data is cloud configuration, security, or billing metadata, and when self-hosting matters: the operators run the CLI and the plugins on their own infrastructure, and they must supply a destination such as a data warehouse, since CloudQuery is the extraction and loading layer rather than the storage. Do not pick it if a fully managed hosted pipeline is required, or if the data is ordinary application data better served by a general-purpose ELT tool. The facts also counsel caution: the project carries 166 open issues, the provided README excerpt is truncated, and no release or version information is available here, so a prospective adopter should check the repository's recent activity and documentation directly before committing.

brew install cloudquery/tap/cloudquery