AVEVA Snowflake: IT/OT Data Unification Architecture for Industrial AI

Every industrial analytics programme eventually hits the same wall. The data that explains why a compressor trips or a batch fails lives in a historian behind a plant firewall, sampled at one-second resolution with engineering tags that only the control engineer understands. The data that decides whether the business cares lives in an enterprise warehouse: orders, maintenance cost, energy contracts, quality claims. Joining the two has historically meant a bespoke pipeline, a quarter of integration work, and a duplicate copy of the process data that drifts out of sync the day it lands.

The AVEVA Snowflake collaboration, announced in Milan on 19 May 2026, is a bet that this pipeline can be replaced by a direct, governed integration between AVEVA CONNECT and Snowflake’s AI Data Cloud. This post separates what AVEVA and Snowflake have actually confirmed from what is inference, then draws a reference data flow you can evaluate against your own estate, and compares it with the Unified Namespace and lakehouse alternatives you may already be running.

What this covers: the confirmed facts of the announcement, the architecture implied by “zero-copy” claims, a four-layer reference design, governance and cost mechanics, failure modes, a decision matrix against alternatives, and a pragmatic evaluation checklist.

Context and Background

Operational technology (OT) data is time-series first. A process historian such as AVEVA PI stores timestamped values per tag, compresses them with exception and swinging-door algorithms, and serves them to trend tools and calculations inside the plant network. Information technology (IT) data is relational and event-oriented: transactions, master data, tickets. The two worlds differ in latency expectations, security model, data semantics, and ownership. That gap is what the industry shorthand “IT/OT convergence” refers to, and it is mostly an organisational and semantic problem wearing a technical costume.

The incumbent answers fall into three families. The first is the historian-centric stack, where the historian remains the system of record and enterprise tools query it through a REST or SQL-like interface; our comparison of AVEVA PI, Cognite Data Fusion and Tulip covers how those platforms position themselves. The second is the message-bus stack, a Unified Namespace built on MQTT and Sparkplug B, in which every site publishes state to a shared broker hierarchy and consumers subscribe. The third is the lakehouse stack, where raw and curated data land in open table formats such as Apache Iceberg and are queried by multiple engines; see our Iceberg production deep dive for the storage mechanics.

Each family has a characteristic failure. Historian-centric stacks keep OT context but struggle to serve a data science team that wants SQL joins against ERP data. Unified Namespace designs excel at real-time state but are not a historical analytics store. Lakehouse designs scale well but force you to build and operate the ingestion, the contextualisation, and the governance yourself.

The announcement matters because it moves the integration point to the platform vendors. AVEVA claims that 90 percent of leading industrial enterprises use its software, and Snowflake reports more than 13,300 customers, per the companies’ own boilerplate in the AVEVA press release. If the integration works as described, a large installed base gains a supported path between the two worlds. Whether it displaces the pipelines people have already built is a separate question that this post tries to answer honestly.

What AVEVA and Snowflake Actually Announced

Before drawing any architecture, fix the facts. The primary sources are AVEVA’s press release datelined Milan, 19 May 2026, and AVEVA’s follow-up announcements from AVEVA World 2026, held in Milan the next day. Trade coverage repeats these and adds little technical detail.

Confirmed by the vendors

AVEVA describes a “strategic collaboration” with Snowflake to accelerate industrial AI and unify IT/OT data ecosystems. The headline claim is a direct, zero-code integration between AVEVA CONNECT, its industrial intelligence platform, and the Snowflake Data Cloud. The release says the integration gives unified access to operational and enterprise data without complex pipelines, supports Snowflake Cortex capabilities for predictive models and AI-driven insights, and carries enterprise-grade governance, security, and scalability.

Two further claims are worth quoting precisely because they are marketing-adjacent. AVEVA says the approach reduces time to value “from months to hours”. Both CEOs describe access “without duplication” or “without the complexity of moving or duplicating data”. Trade coverage, including a report in Intelligent CIO, characterises the mechanism as a zero-copy architecture and lists use cases such as energy optimisation, equipment failure prediction, and real-time operational decisions.

The same coverage states that CONNECT manages over 8 petabytes of industrial data, runs more than 50 SaaS applications, and has more than 23,000 monthly active users. Those are AVEVA-reported platform figures, not benchmarks of the Snowflake integration.

At AVEVA World, the AVEVA World 2026 announcement added context on the roadmap: a CONNECT major release planned for Q1 2027 with an industrial knowledge graph built using agentic AI for asset mapping, improved bulk data movement from AVEVA PI Data Infrastructure into CONNECT, and a Flows capability, from AVEVA’s Crosser acquisition, with more than 800 connectors for real-time processing and hybrid architectures. A separate AWS collaboration built on Amazon Bedrock is distinct from the Snowflake work.

Not disclosed

The announcements do not say which Snowflake mechanism implements “zero-copy”. They do not name the table format, the catalog, whether data crosses a Snowflake secure share or an Iceberg catalog integration, how historian compression and tag context map to Snowflake tables, what the latency is, who pays the compute, or what the licensing is. They do not give a general-availability date in the sources I could retrieve. Treat anything beyond the confirmed list as inference.

Inferred, and labelled as such

Everything in the architecture sections below that describes mechanism, such as the use of Iceberg or secure data sharing, is my inference from how Snowflake documents its open-table and sharing features and how CONNECT stores data. It is a reasoned reference design, not a description of AVEVA’s implementation. When you evaluate the product, ask the vendors to confirm or refute each assumption in writing.

Reference Architecture: From Plant Historian to Snowflake

The architecture question is where the physical bytes live and who moves them. “Zero-copy” in data platform vocabulary usually means that a consumer reads data in place through a pointer or share rather than receiving a physically duplicated and separately governed copy. For industrial data, that raises an immediate puzzle, because the data originates in a historian that is not Snowflake.

Figure 1: Reference data flow from plant sources through AVEVA PI and CONNECT into Snowflake, with governance applied at each boundary.

The diagram shows four layers. Plant sources such as PLCs, SCADA, and sensors feed a local historian, and AVEVA adapters move selected tags into CONNECT. CONNECT holds the cloud-scale industrial data and its context. A sharing or catalog interface exposes governed tables to Snowflake, where they join enterprise data and feed Cortex models and BI. Governance, identity, and lineage span the whole path.

Direct answer: how does the AVEVA Snowflake integration work? AVEVA has confirmed a direct, zero-code link between CONNECT and the Snowflake Data Cloud that lets Snowflake users query industrial data without building pipelines or duplicating it. The exact mechanism, likely a governed share or open-table catalog integration, has not been disclosed, so treat it as an assumption to verify.

Layer 1: plant capture and the historian

Nothing in the announcement changes the plant edge. Controllers still speak OPC UA, Modbus, or vendor protocols; AVEVA adapters or a connectivity layer collect values; the historian stores them with its own compression. This layer matters for architecture because it is where data quality is decided. A tag with a misconfigured engineering unit or a dead-band set too wide cannot be rescued by any cloud integration. If your historian ingestion is weak, read our guide on OPC UA historian to digital twin time-series ingestion before spending on the cloud half.

Layer 2: CONNECT as the cloud industrial data plane

CONNECT is AVEVA’s SaaS platform. Its job in this design is to be the governed, contextualised copy of operational data in the cloud, so Snowflake never has to touch the plant network. That separation is architecturally important: the OT security boundary terminates at CONNECT ingestion, and what Snowflake sees is a cloud-side product. The AVEVA World bulk-transfer improvements for PI Data Infrastructure into CONNECT suggest that backfill of historical data is a first-class concern, which it must be, because a model trained on three weeks of data is rarely useful.

Here the inference begins. Snowflake documents that it can share Apache Iceberg tables across regions and clouds, whether managed by its own Horizon Catalog or by external catalogs such as AWS Glue and Apache Polaris, using what it calls zero-ETL sharing; see Snowflake’s open table format sharing post. One plausible reading of the AVEVA announcement is that CONNECT exposes industrial datasets as open or shared tables that a customer’s Snowflake account reads in place. Another is a vendor-managed Snowflake share with a proprietary schema.

The difference is not academic. In the Iceberg reading, your data is in an open format you can read with other engines, and exit costs are low. In the managed-share reading, you read through Snowflake compute and you depend on the vendor’s schema decisions. Both can legitimately be called zero-copy from the consumer’s side, because no pipeline copies rows into the consumer account. Neither is free: someone pays for storage, someone pays for query compute, and cross-region reads may incur egress.

Layer 4: Snowflake, enterprise context, and Cortex

Once industrial tables are visible in Snowflake, the value comes from joining them with data the plant never sees: work orders, spare-part inventory, production plans, energy tariffs. This is where AVEVA’s claim of moving “operational intelligence into enterprise-wide decision” is concrete. A query that correlates vibration features with maintenance cost per asset class is trivial in SQL and nearly impossible inside a historian.

Cortex is Snowflake’s managed AI layer for functions, models, and agents that run next to the data. AVEVA’s release says the integration supports Cortex capabilities for predictive models. In practice that means feature engineering and inference can run inside Snowflake’s governance perimeter, which matters for regulated customers who do not want process data leaving a controlled account.

The most common reason industrial data projects stall is not transport but meaning. A historian tag named FIC-2041.PV is useless to a data scientist who has never seen the P&ID. Any IT/OT integration that exposes raw tags to the warehouse simply relocates the confusion to a more expensive system. The sensible design places the asset model, units, and hierarchy in the shared layer, so a Snowflake table row says “Feed pump 2, discharge flow, cubic metres per hour” rather than a tag name.

AVEVA’s roadmap item of an industrial knowledge graph built with agentic AI for asset mapping points at exactly this problem. It is planned for Q1 2027 per the AVEVA World announcement, which means that at the time of writing the semantic layer is partly roadmap, not shipped capability. Plan your own asset model work accordingly; our write-up on the Unified Namespace as an industrial data fabric explains why a hierarchical naming convention is worth enforcing at the source regardless of which platform you choose.

Deeper Analysis: What “Zero-Copy” Means for Time-Series Data

Zero-copy is straightforward for relational tables and surprisingly subtle for industrial time series. Three properties of OT data complicate it: volume and cardinality, mutation, and semantics.

Figure 2: Sequence of a cross-domain query, showing where data is read in place and where a physical copy still appears.

Figure 2 follows one analyst query that joins vibration features with maintenance cost. The query is issued in Snowflake, resolved against shared industrial tables, joined with enterprise tables in the same engine, and returned. In the ideal path no rows are copied between systems. The diagram also marks the two places where copies reappear in practice: a materialised feature table for model training, and a cached extract for a BI tool.

Volume, cardinality, and what actually crosses the boundary

A mid-sized plant can easily carry 50,000 tags. Illustrative arithmetic: at one value per tag per second, stored as a timestamp, a 64-bit value, and a quality code at roughly 16 bytes uncompressed, that is 50,000 × 16 × 86,400, or about 69 GB per day before compression. Historian compression with exception reporting commonly reduces stored volume by an order of magnitude or more for slow-moving process variables, but vibration and power-quality signals compress poorly. These figures are illustrative round numbers, not measured values from any customer.

Now compare designs. If you copy raw one-second data for all tags to a cloud warehouse, you pay to move and store the large number. If you share a view that already aggregates to one-minute statistics per tag, the shared volume falls roughly sixty-fold, and a data scientist loses nothing for most daily-cadence models. The architecture question is therefore which resolution you expose, not whether copying happens. A good integration should let you publish multiple resolutions: raw for forensics, one-minute or one-hour aggregates for analytics, and event frames for batch and downtime analysis.

AVEVA has not said what resolutions or aggregates the integration exposes. That is the first thing to ask about in a proof of concept.

Mutation, late data, and corrections

Historians accept late-arriving data and manual corrections. A flow meter recalibrated on Tuesday may have its Monday values restated. Open table formats handle this through snapshot isolation and row-level deletes or merges, but a model trained on Monday’s original values and scored against Tuesday’s corrected values will show an unexplained drift. In a shared, read-in-place design, consumers always see the latest committed snapshot, which is good for correctness and bad for reproducibility unless you also pin snapshots or use time travel for training sets.

Snowflake supports time travel on its native tables, and Iceberg-style snapshots offer a similar property, but you must actually use it. A reproducible training pipeline records the snapshot identifier used for each model version. Without that, you cannot explain a regression six months later.

Semantics: quality codes, units, and timestamps

Three silent errors recur in IT/OT joins. First, quality codes: a historian marks a value as good, uncertain, or bad, and an analytics query that ignores the flag averages sensor faults into the signal. Second, units: a site that reports temperature in Fahrenheit and another in Celsius will produce nonsense in a fleet-wide model unless the shared layer normalises units. Third, time: historians store UTC, but enterprise systems often store local time without a zone, and daylight saving transitions create duplicated or missing hours in joins.

None of these is solved by a transport integration. They are solved by contracts, and the contract has to be written down. A short data product specification per shared table, covering resolution, quality filter, unit, timezone, and update semantics, is worth more than any connector.

Figure 3: Governance layers for a shared industrial data product, from source ownership through contract enforcement to consumption controls.

Governance: who is allowed to see a pump curve

Governance in this context has four distinct concerns. Identity and access decide which Snowflake roles may read which industrial tables; Snowflake offers role-based access control, row access policies, and column masking, and these apply to shared data subject to how the share is configured. Lineage records where a feature came from, which matters for audit in regulated sectors such as pharmaceuticals and energy. Classification marks data that is commercially sensitive, because process parameters can embody trade secrets. Residency decides where data may physically live; a cross-region share may be forbidden for some jurisdictions.

AVEVA’s release asserts enterprise-grade governance and security but publishes no detail. The practical approach is to map the four concerns above into a checklist and ask for evidence on each. If the answer to residency is “it depends on the share type”, you have learned something important about the mechanism.

Cortex and the industrial AI loop

The headline industrial AI use cases in the coverage are energy optimisation, equipment failure prediction, and real-time operational decisions. These are different workloads and should not be lumped together.

Energy optimisation is mostly batch analytics: correlate consumption with production, weather, and tariffs, then recommend schedules. That fits a warehouse well. Failure prediction needs labelled history, meaning maintenance records aligned to sensor features, which is exactly the IT/OT join the integration targets. It runs on daily or hourly cadence and tolerates warehouse latency.

Real-time operational decisions are different. A control loop or an operator advisory that must respond in seconds cannot depend on a cloud round trip through a share and a warehouse query. For those, the model should be trained in Snowflake and deployed to the edge or to a streaming layer near the plant. This is the single most important caveat in the whole architecture: the warehouse is where you learn, not where you act in real time. We return to the edge loop in the alternatives section.

Reference Design: Training in the Cloud, Acting at the Edge

The announcement’s “months to hours” claim is plausible for the first dashboard and implausible for the first closed-loop model. Dashboards need data access; models in production need data access, contextualisation, validation, deployment, monitoring, and a rollback path.

Figure 4: Closed industrial AI loop, with training and joins in Snowflake and inference deployed back near the plant through CONNECT and edge runtimes.

Figure 4 shows the loop. Historical and enterprise data are joined in Snowflake, features are engineered, models are trained and validated there, and the artefact is promoted to an edge or streaming runtime. AVEVA’s June 2026 Operations Control release is described as supporting native C# and Python for edge AI deployment, which is consistent with this pattern, though the announcements do not tie it explicitly to the Snowflake integration. Predictions flow back as events or tags so operators see them in the tools they already use.

Step-by-step: a defensible first use case

Pick one asset class with good instrumentation and a known failure mode, such as centrifugal pumps with seal failures. Publish three shared tables: one-minute aggregates with quality filtering, an event table of maintenance work orders, and an asset dimension table with hierarchy and units. Train a gradient-boosted classifier or a survival model on 18 to 24 months of history, pin the training snapshot, and evaluate on a held-out time period rather than a random split, because random splits leak the future into training for autocorrelated signals.

Deploy the scoring model near the data source, and write the risk score back as a tag. Measure success by avoided unplanned downtime and false-alert load on maintenance planners, not by AUC. A model with strong offline metrics and a 40 percent false-alert rate will be switched off by planners within a month.

Cost mechanics

Cost has three components and the announcement addresses none. Storage is paid wherever the canonical bytes live, which in a CONNECT-hosted design means AVEVA’s subscription terms. Snowflake compute is paid by whoever runs the query, typically the consumer account, and is billed in credits for warehouse time. Data transfer may add egress for cross-region or cross-cloud reads.

An illustrative sizing: suppose an analyst team runs 200 queries per working day against one-minute aggregates, each scanning a few gigabytes on a small warehouse for under a minute. Compute stays modest. Now suppose a scheduled job rescans raw one-second data for 50,000 tags every hour for feature engineering. That workload can cost orders of magnitude more, and it is a pipeline you wrote, not something the integration prevents. These are structural comparisons, not price quotes; use your own contract rates.

The strategic cost question is lock-in. If industrial data is stored in CONNECT and read through Snowflake, you have two vendors with metered economics between you and your own process history. Retaining an independent open-format copy of curated data, even a small one, is an option premium worth paying; see the Iceberg versus Paimon table format comparison for how to choose a format if you build that copy yourself.

Alternatives: Unified Namespace, lakehouse, and the hybrid

The AVEVA and Snowflake path is one of at least three credible ways to unify IT and OT data. Choosing between them depends on where your real-time requirements sit and how much platform engineering capacity you have.

A Unified Namespace publishes plant state over MQTT with Sparkplug B payloads into a hierarchical topic tree, usually Enterprise/Site/Area/Line/Cell. Its strength is real-time, event-driven distribution to many consumers with a single, enforced naming scheme. Its weakness is that a broker is not a store; you still need a historian or lakehouse sink for history. Our Unified Namespace architecture with HiveMQ and Sparkplug B and the comparison of UNS, data mesh, and data fabric describe the pattern in depth.

A self-built lakehouse lands data in Iceberg, Delta, or Hudi tables from a streaming path such as Kafka, and lets any engine query it. It offers the most openness and the most work. The choice among table formats is the subject of our Iceberg, Delta, and Hudi decision record for industrial lakehouses.

The hybrid, which I expect most mature estates to land on, uses the Unified Namespace for the real-time plane, a historian for plant-local history and compliance, and a platform integration such as AVEVA CONNECT to Snowflake for the analytical plane. The announcement fits the third role. It does not replace the first two.

Dimension	AVEVA CONNECT to Snowflake	Unified Namespace plus lakehouse	Historian only
Time to first dashboard	Vendor claims hours; unverified	Weeks to months	Days, but plant-local
Real-time actuation	Not the target; use edge	Strong via broker	Limited
Openness of stored data	Depends on undisclosed mechanism	High	Low to medium
Engineering effort	Low for access, still high for semantics	High	Low
Vendor dependency	AVEVA and Snowflake	Component vendors, swappable	AVEVA or peer
Enterprise joins	Native in Snowflake	Via lakehouse engine	Poor
Best fit	Existing AVEVA estates with Snowflake already adopted	Multi-vendor, high-customisation	Single-site monitoring

The matrix is a qualitative judgement from the public facts, not a benchmark. Re-score it after a proof of concept on your own data.

How this fits with existing AVEVA PI estates

Many readers run PI Server today and are not on CONNECT. The announced integration is CONNECT to Snowflake, so the first dependency is a CONNECT subscription and a working PI-to-CONNECT data path. The AVEVA World notes on improved bulk movement of PI Data Infrastructure into CONNECT and web-based adapter management reduce but do not remove that migration cost. If you are not already on that path, the real project is “adopt CONNECT”, with Snowflake access as the dividend.

It is also worth reading the announcement against AVEVA’s broader positioning in our AVEVA PI versus Cognite Data Fusion versus Tulip comparison. Cognite and others pursue their own contextualised industrial data models and have their own warehouse integrations. The competitive pressure is part of why vendors are announcing partnerships rather than building walled gardens.

Trade-offs, Gotchas, and What Goes Wrong

The integration reduces one class of work and exposes several others. These are the failure modes I would plan for.

Semantic debt arrives faster. Easy access means analysts query industrial tables before the asset model is clean. They build dashboards on mislabelled hierarchies, executives trust them, and correcting the model later invalidates published numbers. Gate access to tables that have an owner and a data contract.

Latency is misunderstood. “Real-time operational decisions” in marketing copy rarely means control-loop latency. Share-based reads are subject to catalog refresh and snapshot commit intervals. If your use case needs sub-second response, build it at the edge. Ask for the end-to-end freshness figure, measured from historian write to Snowflake visibility, and ask for it at the 95th and 99th percentiles, not the average.

Zero-copy hides second copies. Feature tables, BI extracts, and model training sets are all copies, created by your own team. Without lifecycle rules, you end up with the duplication the integration promised to remove, now outside the governed share. Track every derived table to a source and an owner.

Governance gaps at the seams. Role-based access in Snowflake does not automatically mirror plant-level or site-level access rules in CONNECT. A contractor with read access to one site’s historian should not see fleet-wide tables. Verify that row-level policies propagate through the share and are tested, not assumed.

Exit cost. If the integration depends on proprietary schemas or a share type that cannot be read by other engines, switching later means rebuilding the data path. Ask whether an open-format option exists.

Roadmap dependency. The industrial knowledge graph is a Q1 2027 item in AVEVA’s announcement. Projects that assume it on day one will stall. Similarly, treat the “months to hours” claim as a statement about connection setup under favourable conditions, not about a production model.

Security surface. A cloud-to-cloud integration moves the OT boundary question upward. The plant firewall no longer protects the data once it is in CONNECT. Review identity federation, key management, and audit logging as you would for any cloud data platform, and check regulatory requirements such as IEC 62443 zone and conduit design for the ingestion edge.

Practical Recommendations

If you run AVEVA and already hold a Snowflake contract, the integration is worth a bounded proof of concept. If you run neither, it is not a reason to adopt both. If you run a multi-vendor estate with a Unified Namespace, treat it as one possible analytical sink, not the centre of your design.

Run the proof of concept as an experiment with explicit acceptance criteria rather than a demo. Pick one asset class and one business question, and require the vendors to answer the undisclosed items in writing before you commit: mechanism, table format, catalog, resolutions, freshness, residency, and pricing split.

Confirm general availability status, supported regions, and licensing for the CONNECT to Snowflake integration in your contract region.
Ask which share or catalog mechanism is used, and whether Iceberg or another open format is available.
Define data products with owner, resolution, quality filter, unit, and timezone before exposing them.
Measure end-to-end freshness at the 95th and 99th percentiles under production load.
Test row-level and column-level policies with a restricted role, including cross-site access.
Pin training snapshots and record the snapshot identifier with each model version.
Keep real-time inference at the edge; use Snowflake for training, joins, and fleet analytics.
Budget Snowflake compute with resource monitors, and cap scheduled rescans of raw data.
Keep an independent open-format copy of curated data to preserve exit options.
Revisit the decision when the Q1 2027 knowledge graph release ships and has independent reviews.

Frequently Asked Questions

What did AVEVA and Snowflake announce?

On 19 May 2026 in Milan, AVEVA announced a strategic collaboration with Snowflake to integrate AVEVA CONNECT directly with the Snowflake Data Cloud. The stated goals are zero-code access to unified IT and OT data, support for Snowflake Cortex AI capabilities, enterprise governance, and no unnecessary data duplication. The companies have not published implementation details such as the table format, latency, or pricing, so assess it as a direction backed by marketing claims until verified.

Does the AVEVA Snowflake integration replace a historian like PI?

No evidence in the announcement suggests that. The historian remains the plant-local system of record for high-resolution, low-latency data and compliance. The integration targets the cloud analytics plane by exposing CONNECT-held industrial data to Snowflake users. AVEVA’s own AVEVA World roadmap continues to invest in PI Data Infrastructure, including bulk transfer into CONNECT, which implies PI remains a source rather than a casualty of this collaboration.

What does zero-copy mean for industrial data?

It means consumers read data in place through a share or catalog rather than receiving a separate physical copy via a pipeline. It does not mean no storage cost, no compute cost, or no copies anywhere. Derived feature tables, BI extracts, and model training sets still create copies. For time series, the practical decision is which resolution you expose, since sharing one-minute aggregates rather than raw one-second values changes volume dramatically.

Can Snowflake do real-time industrial AI at the edge?

Not on its own. Snowflake is well suited to training models, joining enterprise data, and fleet-wide analytics. Control-loop or operator-advisory latencies of seconds or less need inference deployed near the plant, on an edge runtime or streaming layer. A sound pattern is to train and validate in Snowflake, deploy the model to the edge, and write predictions back as tags or events that operators already see.

How does this compare with a Unified Namespace?

They solve different problems. A Unified Namespace built on MQTT and Sparkplug B distributes real-time state with a consistent naming hierarchy, but it is not a historical analytics store. The AVEVA and Snowflake integration targets analytical joins and AI over historical and enterprise data. Many mature architectures combine both: the namespace for the real-time plane and a platform integration or lakehouse for the analytical plane.

Is the AVEVA and Snowflake integration generally available?

The sources I retrieved, namely AVEVA’s press release and AVEVA World announcement, do not state a general-availability date for the Snowflake integration. Check AVEVA’s current documentation and your account team before planning around it. Some other AVEVA World items have stated dates, such as Operations Control in June 2026 and the CONNECT major release in Q1 2027, but those are separate from this integration.

AVEVA and Snowflake: IT/OT Data Unification Architecture for Industrial AI

AVEVA Snowflake: IT/OT Data Unification Architecture for Industrial AI

Context and Background