Eighty Per Cent of Satellite Data Goes Unused: The Case for a Commercial DataOps Layer

3 days ago
10 min read

The utilisation gap

Europe operates the most ambitious public Earth observation data infrastructure on the planet. The Copernicus Data Space Ecosystem holds nearly 80 petabytes of data online and produces up to 30 terabytes daily [Source: CDSE Annual Reports, 2023-2024]. Before its migration to CDSE, the Sentinel Data Access system recorded nearly 760,000 registered users. Total downloads reached 586 pebibytes since the start of operations [Source: Ninth Copernicus Sentinel Data Access Annual Report, 2023]. By any measure of supply, the system works. Commercial consumption tells a different story. Global EO data and services revenues reached EUR 3.4 billion in 2023, set against a downstream space market of EUR 358 billion [Source: ESA Report on the Space Economy, 2024]. Value-added services account for 62 per cent of downstream EO revenue today, with projections reaching approximately 80 per cent by 2033 [Source: EUSPA EO and GNSS Market Report, Issue 2]. The money sits above raw imagery, in the processing, analysis, and delivery layers. Yet the firms generating that revenue remain fragmented. Over 700 European EO services companies build bespoke internal pipelines to make satellite data usable [Source: EARSC Industry Survey]. No official source provides a direct percentage of commercial versus non-commercial consumption. The available metrics quantify platform usage and distribution performance, not end-market monetisation. Registered users, products published, and bytes downloaded measure infrastructure throughput. They do not measure whether data reaches a business decision. The "eighty per cent" framing in this article's title is a directional inference. It rests on several convergent data points. These include the ratio of data produced to data commercially consumed, the small number of production-grade commercial pipelines, and the fragmentation of the European EO services sector. When 30 terabytes arrive daily and the commercial processing infrastructure to absorb them remains thin, the gap is structural. That gap is not about data availability. Copernicus data is free, full, and open. The CDSE handles two billion catalogue queries monthly and sustains up to 1,000 catalogue queries per second [Source: CDSE Annual Report, 2024]. The infrastructure performs at scale. The gap is about data operability. It is the distance between a satellite product file and a reliable, governed, enterprise-grade data feed. A business user should not have to become a remote sensing engineer to consume it.

Why the gap exists

The barrier to commercial adoption is not interest. Insurance underwriters want flood extent polygons. Infrastructure operators want deformation alerts. Agricultural lenders want crop condition indices. The barrier is engineering. Raw satellite data requires specialised cleaning, normalisation, and transformation before it can feed any analytical model. ESA's own market taxonomy decomposes downstream EO into data sales (38 per cent) and value-added services (62 per cent). Value-added work begins as early as advanced calibration [Source: ESA Report on the Space Economy, 2024]. That decomposition reveals where effort concentrates. Most commercial value sits in the work done after the data leaves the satellite and before it reaches the end user. Three bottlenecks dominate the time-to-insight problem in European commercial EO workflows. The first is data discovery and product selection. Even with STAC catalogues and standardised APIs, teams lose time identifying correct products, harmonising metadata, and constructing repeatable queries. The CDSE architecture now incorporates STAC-based catalogue services and standardised endpoints precisely because discovery friction is a core constraint [Source: CDSE documentation]. The second is preprocessing and analysis readiness. Atmospheric correction, cloud masking, resampling, temporal compositing, quality control: these are deterministic transformations. They must be robust before any machine learning or analytics can be reliable. The Committee on Earth Observation Satellites defines Analysis Ready Data standards (CARD4L) that specify what "ready" means operationally [Source: CEOS ARD Framework]. Most commercial users cannot implement these transformations themselves. The work is not optional. Sentinel-2 optical imagery, for example, operates on a five-day revisit cycle, which means cloud contamination forces temporal compositing across multiple passes [Source: ESA Sentinel-2 Operations]. SAR data from Sentinel-1 requires calibration, terrain correction, and speckle management before any analytical use. These are engineering problems with known solutions, but solutions that demand sustained operational investment. The third is delivery integration into enterprise systems. Enterprises do not consume satellite data as GeoTIFF files. They consume APIs, event streams, database tables, and dashboards integrated into claims systems, asset management platforms, and compliance portals. Sentinel Hub's market positioning is instructive here. It frames its value as removing the need to download imagery, handle JP2 files, reproject, mosaic, and provision storage [Source: Sentinel Hub developer documentation]. That is a middleware pitch, not an analytics pitch. It targets the operational bottleneck, not the science. For foundation models consuming EO data, the pipeline requirements become even more exacting. Models such as TerraMind (the ESA-IBM collaboration) and Prithvi-EO-2.0 require consistent spatial alignment, radiometric comparability, masking of invalid observations, and clear provenance [Source: TerraMind paper, 2025; Source: Prithvi-EO-2.0 model card]. "Model-ready" is economically valuable work. It is data engineering, not technical hygiene. The gap between "satellite" and "business user" is an engineering problem. More precisely, it is a data operations problem: ingestion, preprocessing, cataloguing, lineage, quality control, and delivery at production cadence with enforceable service levels. Every organisation that wants to use satellite data commercially must either build this pipeline internally or buy it. Today, almost everyone builds it internally, badly, and expensively.

What exists today

A thin layer of European platforms occupies part of the middleware space. Two hyperscaler platforms set the standard for developer experience. Nobody fills the full gap. The CDSE itself now incorporates middleware-like functions: STAC catalogues, openEO processing, S3-protocol access, and JupyterLab environments [Source: CDSE documentation]. These are real capabilities. They lower the barrier for developers and researchers. The openEO interface formalises processing graphs, making jobs portable across backends and reducing vendor-specific coupling [Source: CDSE openEO documentation]. But the CDSE is a distribution system, not a commercial DataOps platform. It does not offer enterprise SLAs, governed multi-tenant access, or integration into non-EO business systems. Its authentication model provides a baseline identity layer, but enterprise contexts typically require federation and internal IAM bindings. Sentinel Hub, originally Slovenian and now part of Planet Labs, offers tiered subscriptions with processing unit accounting. Pricing ranges from roughly EUR 30 per month to EUR 1,000 per month. Batch APIs and commercial data features are restricted to higher tiers [Source: CREODIAS pricing]. It is the closest thing in Europe to a production EO middleware product. UP42, incubated from Airbus and BCG in Berlin, operates a credit-based API marketplace with per-square-kilometre billing and minimum charge areas [Source: UP42 documentation]. Its pricing model demonstrates that geospatial billing logic (area multiplied by acquisitions, minimum order thresholds, dynamic cost estimation) is inseparable from platform architecture. Outside Europe, Google Earth Engine hosts over 90 petabytes across more than 1,000 curated datasets with server-side processing [Source: Google Cloud Earth Engine product page]. Microsoft Planetary Computer provides STAC-based cataloguing as an Azure-native product with explicit commercial pricing [Source: Microsoft Planetary Computer Pro documentation]. Both set expectations for catalogue depth and developer experience that no European entrant can replicate quickly. Their combined advantage is not a feature checklist; it is economies of scale built over years of sustained investment. European EO services revenue, approximately EUR 1.7 billion in 2022, is generated across more than 700 companies [Source: EARSC Industry Survey]. The middleware-layer firms (Sinergise, EOX, and similar organisations) are typically small, software-heavy operations, not labour-heavy consulting firms. They serve parts of the pipeline well. None runs the full chain as a commercial, governed, enterprise-grade product. None offers metering, SLAs, and integration into non-EO business systems as a single managed service. Parts of the pipeline exist. The full product does not.

Why a data engineering firm, not a space company or an AI lab

The missing layer is not a space problem. It is an enterprise data platform problem with a different source system. Understanding why clarifies who is most likely to build it. Space agencies build public infrastructure. ESA and EUSPA operate under mandates for access, uptake, and societal benefit. The CDSE distributes data at scale and increasingly offers processing interfaces. But a public distribution system optimised for broad access is structurally different from a commercial DataOps platform. The latter requires governed, metered, SLA-backed delivery to enterprise buyers. The agencies recognise this gap. EUSPA's "Make it with Space" procurement launched in February 2026 with a EUR 16.5 million ceiling [Source: EUSPA, 2026]. It explicitly targets operational integration of space solutions into non-space sectors. The gap is acknowledged at institutional level. Satellite operators are vertically integrated around their own constellations and data products. Their platforms optimise for their own data sales. When Planet Labs acquired Sinergise (the company behind Sentinel Hub), it gained a middleware layer. That layer remains tightly coupled to its own commercial data business. When Airbus incubated UP42, it built a marketplace anchored to its own imagery products. These are rational business choices. They are not horizontal, multi-source pipeline operations designed to serve a customer's full data estate across sensors and providers. AI labs jump to the model layer. Foundation models need stable, governed, repeatable input data. Without the pipeline, the model has nothing reliable to consume. The TerraMind paper itself notes that even out-of-the-box generative outputs have limits compared to specialised supervised models in some contexts [Source: TerraMind paper, 2025]. Production performance depends on task-specific adaptation, careful evaluation, and strong data engineering. The AI lab depends on the DataOps layer but rarely builds it. A data engineering firm already builds the subsystems an EO pipeline requires. Catalogue integration, workflow orchestration, metering and billing logic, governance and access control, enterprise integration: these are its core business. The source data changes. Spatio-temporal rasters replace business tables. But the engineering patterns transfer cleanly: ETL, data quality gates, API-first delivery, cost attribution, lineage, and operational monitoring. Consider the specific subsystems. A production EO pipeline needs STAC-based catalogue harvesting and metadata normalisation. It needs job orchestration with retry logic, versioning, and CI/CD for pipeline code. It needs processing unit accounting and quota enforcement, because platforms like CDSE and Sentinel Hub already meter access this way [Source: CDSE documentation]. It needs OpenID Connect authentication, multi-tenant access controls, and auditable access logs [Source: CDSE openEO authentication documentation]. Every one of these is standard enterprise data platform engineering. The geospatial specifics (coordinate reference systems, tiling, raster formats) add a learning curve. They do not require a fundamentally different engineering discipline. The regulatory environment reinforces this argument. NIS2 establishes cybersecurity obligations across 18 critical sectors and explicitly covers digital infrastructure providers [Source: European Commission NIS2 policy page]. The Cyber Resilience Act imposes essential cybersecurity requirements on software products placed on the EU market. Substantive requirements phase in over three years from December 2024 [Source: European Commission CRA summary]. GDPR applies wherever EO-derived features are fused with personal data. The AI Act raises documentation and governance requirements when EO-derived AI contributes to high-stakes decisions [Source: European Commission AI Act summary]. In aggregate, these regulations change the unit economics of EO DataOps. They push cost into access controls, audit logging, incident response, and change management. They increase procurement friction for non-EU or low-maturity providers where data residency and incident reporting obligations cannot be credibly met. For small EO startups, this compliance overhead is expensive to build from scratch. For firms already serving regulated industries, it is standard operating procedure. The firms best positioned to build the missing commercial DataOps layer already run governed, production-grade data pipelines for regulated buyers. The space domain provides the source data. The engineering discipline comes from somewhere else.

The commercial opportunity

The timing, market structure, and institutional signals point toward this gap being filled in the next three to five years. EO revenues are forecast to reach approximately EUR 6 billion by 2033, with value-added services at approximately EUR 5 billion [Source: EUSPA EO and GNSS Market Report, Issue 2]. That growth is concentrated in the layers above raw imagery, where pipeline operations sit. The insurance and finance segment alone is projected to grow approximately 165 per cent from 2023 to 2033, reaching approximately EUR 900 million [Source: EUSPA EO and GNSS Market Report, Issue 2]. Insurance buyers need governed, auditable, repeatable data feeds. They do not need another research prototype. Institutional investment is directional. ESA's CM25 ministerial committed EUR 22.3 billion, the largest contributions package in the agency's history [Source: CM25 Subscription Tables]. Within that envelope, EUR 306 million went to the ACCESS commercialisation programme [Source: CM25 Subscription Tables]. EUR 86 million went to Digital Twin Earth, and approximately EUR 842 million to European Resilience from Space EO elements [Source: CM25 Subscription Tables]. These are not research curiosities. They are operational programme budgets that will generate persistent downstream workloads in data handling, integration, and governed delivery. The Destination Earth initiative adds a second data plane. Its Data Lake spans five data centres across Europe and exposes a STAC-based Harmonised Data Access API [Source: DestinE Data Lake documentation]. DestinE connects to CDSE, meaning Copernicus observational streams and DestinE simulation outputs will flow through interconnected infrastructure [Source: DestinE Data Exploitation Hub documentation]. For downstream operators, DestinE expands the addressable market from EO analytics to model-informed decision products: risk scores, scenario stress tests, and parameterised projections. These products sit closer to enterprise procurement needs than raw imagery. The European Investment Bank launched Space TechEU with EUR 500 million in expected financing [Source: EIB, November 2025]. The programme aims to mobilise EUR 1.4 billion in investment with commercial banks. Horizon Europe includes a dedicated Space Data Economy topic for 2026, targeting clean energy, climate adaptation, green financing and insurance, and sustainable cities [Source: EUSPA Horizon Europe call page]. These are verticals where recurring data requirements, regulatory reporting obligations, and auditability demands create natural demand for enterprise-grade pipelines. The regulatory stack functions as a competitive moat. NIS2, the Cyber Resilience Act, GDPR, and the AI Act increase procurement friction for non-EU or low-maturity providers. Public sector and critical infrastructure buyers in scope sectors require demonstrable cybersecurity controls, incident reporting readiness, and supply-chain security. Firms with an existing compliance posture can meet these requirements as standard operating procedure. Firms without one face material cost and time barriers to entry. Three forces are converging. A growing market concentrates value in the processing and delivery layers. Institutional programmes explicitly fund operational integration rather than pure research. A regulatory environment advantages firms with mature governance and security practices. The question is not whether a commercial DataOps layer will be built for European satellite data. The question is who builds it first.

Wiz Digital is an Irish research and engineering company headquartered in Cork. The company investigates hard technologies, prototypes and tests solutions, and deploys them for industries that need results they can measure. What Wiz Digital ships, it built. What it built, it researched. The company operates across data engineering, AI, cloud infrastructure, and enterprise integration. Its work spans regulated industries including financial services, housing, infrastructure, and public sector organisations. Wiz Digital won the Smart Technology Innovation award at the Tech Industry Alliance Leaders Awards 2025.