Carbon capture, utilization, and storage has a data problem — and it's not the one most people think.
The obvious data challenge is tracking projects. How many CCUS projects exist globally? How many have reached final investment decision? What's the total announced capture capacity? Multiple databases attempt to answer these questions. The IEA CCUS Projects Explorer covers large-scale projects worldwide since the 1970s. The Global CCS Institute maintains its CO2RE database. NETL publishes a CCS database for the U.S. Department of Energy.
More counting is not what the industry needs. What it needs is connected data — structured intelligence that links capture facilities to the transport routes and storage sites that make them viable.
CCUS is a system, not a project
This is the fundamental distinction that most databases miss. A carbon capture installation at an industrial facility is useless without somewhere to put the CO₂. That "somewhere" involves a chain: pipeline or shipping transport to a geological storage formation or a utilization pathway. Each link in that chain is a separate project, with a separate developer, separate permitting, separate financing, and a separate timeline. If one link stalls, the entire chain breaks.
This means that the most important questions in CCUS market intelligence aren't about individual projects. They're about system viability: Does the proposed capture facility have access to transport infrastructure? Is the transport route connected to a storage site with confirmed geological characterization? Are the timelines aligned?
Why existing databases fall short
Most CCUS databases are structured as flat project lists. Each row is a project. The columns contain attributes: name, location, developer, capture capacity, technology type, status, year. Some databases distinguish between capture, transport, and storage projects. A few include utilization pathways.
But the relationships between these projects — which capture facility connects to which pipeline, which pipeline feeds which storage site — are either missing entirely or described in free-text notes that can't be queried programmatically.
The storage bottleneck is invisible in project counts
Multiple capture projects in a given region may all cite the same offshore storage formation as their intended CO₂ destination. Each project's individual capacity figure looks plausible. But the total claimed capacity across all projects citing that formation may exceed what the geological assessment supports.
This oversubscription problem is invisible in databases that treat each project as an independent row. It only becomes visible when you model the relationships.
What we track differently
Our approach to CCUS data is built on the same graph-based architecture we use across all 37 sectors, but the specific entity types and relationships are tailored to how CCUS systems actually work.
Capture entities include the industrial facility or power plant where CO₂ is captured, the capture technology deployed, the designed capture capacity, the capture rate, and the project's status and timeline.
Transport entities include pipeline projects, shipping routes, and other CO₂ logistics infrastructure. Critically, transport entities are linked to both the capture sources they serve and the storage destinations they connect to.
Storage entities include geological formations, their characterized capacity, injection rate limits, and regulatory status. Storage entities link to the transport routes that deliver CO₂ and, through those routes, to the capture sources that depend on them.
The bottom line
CCUS will not scale by adding more rows to project databases. It will scale when the infrastructure connecting capture to storage is financed, built, and operated — and making investment decisions about that infrastructure requires data that models the system, not just the components.