AVEVA PI vs Cognite Data Fusion vs Tulip: Industrial DataOps Compared (2026)

Most procurement committees treat the AVEVA PI vs Cognite Data Fusion question as a bake-off between three interchangeable “industrial data platforms”, add Tulip as a third column, and then wonder why the scoring spreadsheet produces nonsense. The reason is simple: the three products start from different primitives. PI starts from the tag stream. Cognite Data Fusion starts from a typed graph of assets, files and events. Tulip starts from the operator’s screen. Each can be stretched toward the others, and each stretch has a cost that rarely shows up in a demo.

This matters in late 2026 because all three vendors have moved at once. AVEVA is pushing PI data into its CONNECT platform and promising a knowledge graph. Cognite has shipped an Industrial MCP preview so that external AI agents can query its graph. Tulip is marketing an AI-native composable MES. The overlap is growing, and so is the temptation to buy one platform to do everything.

You will leave with a mechanism-level view of each architecture, an honest comparison of data modelling, AI readiness, edge and Unified Namespace (UNS) fit, a lock-in analysis, migration paths, and a scenario-based selection guide.

What this covers: the three architectural philosophies, data modelling head to head, ingestion and UNS integration, the AI story, licensing logic, lock-in and migration, failure modes, and a practical decision checklist.

Context and Background

Industrial DataOps is the discipline of getting operational technology (OT) data out of controllers and into a state where analysts, applications and models can trust it. That includes collection, normalisation, contextualisation (knowing which pump a tag belongs to and which work order touched it), quality control, and governed access. The term is newer than the products. The plant historian has existed since the 1980s, and the AVEVA PI System (originally OSIsoft PI, now part of AVEVA, which Schneider Electric took private in 2023) is the best-known one. Cognite was founded in Norway to solve the contextualisation problem for heavy-asset operators, and Tulip grew out of a “frontline operations” idea: give operators no-code apps and connected devices instead of paper.

So the incumbents are not competing on one axis. A useful way to separate them is to ask what each treats as the unit of value. For a historian, it is the tag: a named, timestamped, compressed stream. For Cognite it is the asset-centred knowledge graph, where time series are one attribute among many. For Tulip it is the app and the record an operator creates by using it. Pricing, scaling limits and failure modes all follow from that choice, which is why a feature checklist misleads.

A second reason the comparison is hard is that AVEVA’s own positioning has shifted. The PI System is no longer sold only as on-premises servers. AVEVA describes PI Data Infrastructure as a hybrid of Edge Data Store, PI Server and CONNECT data services, and its April 2025 roadmap lists agents that move data from PI to CONNECT and (in development) back to PI tags. Anyone reading a 2022-era PI comparison is reading about a different product shape. I will flag where I am relying on vendor roadmap statements, which are intentions rather than shipped features.

If you are new to how historians sit relative to SCADA and OPC servers, our piece on SCADA vs OPC vs IoT platform vs data historian covers the layering, and the SCADA and historian architecture post goes into the storage side. For the wider vendor and standards picture on the IT side, AVEVA’s CONNECT announcements reported by Engineering News are a good snapshot of where PI is heading.

One caution before the deep dive: I score on architecture, not on who has the nicer sales deck. Where I describe pricing it is qualitative, because all three vendors price by negotiation and I will not invent numbers.

Three Architectures, Three Primitives

AVEVA PI is a time-series historian with an asset layer on top, Cognite Data Fusion (CDF) is a cloud knowledge graph that ingests time series alongside documents and events, and Tulip is an app platform whose data model is the by-product of operator workflows. The practical difference is where context lives: above the tags in PI, in the graph in CDF, and in the app in Tulip.

Figure 1: Three industrial DataOps paths. PI is tag-first, Cognite is graph-first, Tulip is app-first.

The figure shows each platform as a pipeline from the plant floor to the consumer. The shapes differ more than the labels suggest: PI’s pipeline ends in trends and calculations, Cognite’s ends in a graph that apps and agents query, and Tulip’s ends in an operator-facing app whose records feed back into tables.

AVEVA PI: the tag store with a context layer

The heart of a PI System is the Data Archive, which stores timestamped values per point (the tag) using a compression scheme that discards samples that can be reconstructed within a tolerance. That design makes long retention cheap and reads very fast for the question historians were built for: what did this signal do between two timestamps. Around it sit the Asset Framework (AF), which models equipment as templated elements with attributes that reference tags, plus Event Frames for bounded occurrences such as batches and downtime, analytics, notifications and PI Vision for browser dashboards.

Data arrives through interfaces and, in current generations, AVEVA Adapters. AVEVA’s April 2025 roadmap lists adapters for OPC UA, DNP3, BACnet, Modbus TCP, RDBMS and MQTT, with edge modules and adapter failover in development. Hybrid operation is the newer theme: PI to CONNECT agents forward data to the cloud, and the roadmap lists writing CONNECT streams back to PI tags as in development.

The strength is operational trust. PI is deeply embedded in control-room workflows, change-managed, and understood by OT engineers who will not trust anything else with a compliance report. The weakness is that AF is a hierarchy-and-template model. It handles “this reactor and its sensors” very well, and handles “this reactor, its P&ID, the inspection photographs, the last three work orders and the lab results” poorly, because those objects are not tags.

Cognite Data Fusion: the graph with time series attached

CDF is a cloud-native industrial data platform. Its ingestion layer consists of extractors, including OPC UA, PI, SAP OData and file extractors, plus hosted extractors for MQTT, Kafka, REST and Azure Event Hubs, according to Cognite’s own material. Raw data lands in a staging area, transformations written in SQL shape it, and the result populates a data model.

That data model is the point. Cognite’s Core Data Model is a shared base schema for industrial concepts that customers extend with industry models or custom ones, and Cognite claims it halves deployment time for new customers (a vendor claim I cannot independently verify). Assets, files, events, 3D models and time series are nodes with typed relations, so a query can walk from a pump to its documents to its sensor history without a join across systems.

The cost is that you now run a data engineering practice. Someone must own the modelling, the transformations, the extraction pipelines and the quality rules. CDF gives you tooling for this, and the Q3 2026 release even adds a Foundation Deployment Pack that sets up access groups, the data model, extraction pipelines and CI/CD in one guided pass, which tells you how much scaffolding was previously manual.

Tulip: the app that creates its own data

Tulip is a no-code platform for building operator apps, running on tablets and stations, with Edge devices that connect machines, sensors and scanners, a connector framework and open API for integration, and a library of pre-built integrations. Its Tulip Tables hold structured records that apps read and write. The company positions the whole as a composable MES, and its own material describes configurable AI agents, no-code computer vision on low-cost cameras, and an operator copilot.

Tulip’s data model is therefore a means to an end. It captures what operators did (a step completed, a defect logged, a part consumed) with strong traceability, but it is not designed to ingest 50,000 tags at one-second resolution for ten years. That is not a criticism. It is the reason Tulip belongs next to a historian rather than instead of one.

Why the primitive decides everything else

If the primitive is the tag, then scale is measured in tags and writes per second, storage is compressed time series, and queries are range reads. If it is the graph, scale is nodes, edges and query depth, and the hard problem is identity: making sure that “P-101”, “PUMP101” and the SAP functional location resolve to the same node. If it is the app record, scale is stations and users, and the hard problem is change control on the workflows themselves.

You can see the consequences in how each vendor handles the others’ territory. PI added AF and Event Frames to get toward context, and now CONNECT and a promised knowledge graph (AVEVA’s roadmap names a major release for Q1 2027, a plan not a product). Cognite added time series features such as state time series and gap filling to get toward historian ergonomics. Tulip added edge devices and connectors to pull machine data into apps. Each is acquiring the neighbour’s capability, usually at the neighbour’s depth minus one level.

Data Modelling: Historian vs Knowledge Graph vs Table

The core modelling difference is that a historian answers “what did signal X do”, a knowledge graph answers “what is connected to asset Y and what happened to it”, and a table-based app answers “what did the operator record at step Z”. Choose by the question you ask most often, not by the feature list.

Figure 2: How each platform reaches a question. PI goes time-first, Cognite goes relationship-first, Tulip goes record-first.

The figure converges on the question asked because that is the real test. Any of the three can eventually answer any question; the difference is how much work sits between the question and the answer.

Worked example: why is pump P-101 vibrating?

Take a concrete case. A maintenance engineer asks why pump P-101 shows rising vibration. In a PI-centred stack, the engineer opens PI Vision on the AF element for P-101, sees vibration, motor current and discharge pressure trends, and compares to a baseline. That is excellent and fast. To learn that the seal was replaced two weeks ago, they leave PI for the maintenance system; to see the P&ID, they open a document system; to see if sister pumps behave the same way, they use AF templates and compare elements, which works well when the templates are clean.

In a CDF-centred stack, P-101 is a node. Its time series, the work orders from the maintenance system, the P&ID file with the pump annotated, the inspection images and the 3D position are all linked to that node. The same question becomes one traversal. The price is paid earlier: someone had to ingest the work orders, run entity matching to link the P&ID annotations to the asset, and keep the links alive when the asset hierarchy changes.

In a Tulip-centred stack, the question is mostly about what the operator observed. If the plant runs a Tulip app for pump rounds, the record of “abnormal noise noted at 14:20, photo attached” lives in a Tulip Table with the station and operator, which no historian or graph captured. That makes Tulip a valuable source of context rather than a competitor to the other two.

Time series semantics

Time series handling is where historians still earn their keep. PI’s compression, interpolation and step-versus-continuous point types are decades of accumulated behaviour that control engineers rely on. For instance, whether a value is held between samples or interpolated changes calculated averages, and OT teams have strong opinions.

Cognite has been closing this gap. The Q3 2026 release notes describe a State Time Series type with aggregates such as state duration, state transitions and state count (public preview), and opt-in gap filling on aggregate queries with a configurable limit and OPC UA-style interpolation (public preview). Both are preview features as of that release, so verify GA status before you depend on them.

Hierarchy and templates vs flexible types

AF’s template mechanism is its best idea. You define a pump template once, with attributes mapped to tag naming conventions, and instantiate it hundreds of times. Change the template and every element follows. This is why large PI estates stay manageable, and the discipline it imposes is also why many sites have a clean asset tree that a graph platform can import.

CDF’s data modelling lets you define types with properties and relations, and you can approximate templating through views and inheritance from the Core Data Model. It is more expressive (graph relations, not only parent-child) and correspondingly easier to model badly. The practical advice from projects I have seen: start with the Core Data Model unchanged, add one custom view at a time, and refuse to model anything you cannot name a consumer for.

Tulip tables are deliberately simple. They suit batch records, nonconformances, checklists and kitting, where the schema is small and the audit trail matters more than the shape. Trying to represent an equipment hierarchy there is a sign you are using the wrong tool.

Where identity breaks

Whichever platform you choose, identity management is the unglamorous determinant of success. Tags are named by controls engineers, assets by maintenance planners, and parts by ERP. A knowledge graph only helps if these resolve. AF can host the tag-to-asset mapping inside PI; CDF offers contextualisation tooling and entity matching, which I treat as a helpful accelerator and never a guarantee, because match quality varies with naming consistency; Tulip typically relies on explicit selection by the operator or a barcode.

A good test during a proof of concept: take 200 real tags from a messy area, and measure how many resolve to the right asset with no manual correction. The percentage tells you more about your project than any benchmark.

Ingestion, OPC UA, MQTT and the Unified Namespace

All three platforms can consume a Unified Namespace, but none should be the thing that creates one. Put the namespace in an MQTT broker fed by an edge gateway, then let each platform subscribe for what it needs, so no vendor owns your topic tree.

Figure 3: A neutral broker-centred pattern. Each platform is a subscriber, and PI can also forward into CDF through an extractor.

The figure shows the pattern I recommend. An edge gateway acts as an OPC UA client and publishes to an MQTT broker; PI’s MQTT adapter, Cognite’s hosted MQTT extractor and a Tulip connector or edge device each subscribe independently. The dashed line shows the common brownfield reality that CDF also reads from PI directly.

OPC UA as the source of truth for structure

OPC UA carries structure (nodes, types, companion specifications) as well as values, which is why it remains the best southbound protocol. Cognite’s OPC UA extractor and PI’s OPC UA adapter both read it; Tulip typically reaches machines through its edge devices and connectors. For the lower layers, see how OPC UA historian data feeds a digital twin ingestion pipeline and the trade-offs in OPC UA vs MQTT Sparkplug B.

The subtle point is that when you flatten OPC UA into MQTT topics you lose type information unless you preserve it in payload design. Sparkplug B retains some metadata and state management that plain topics do not; our comparison of Sparkplug B vs plain MQTT topics explains the cost of skipping it.

How each platform consumes MQTT

PI’s route is an adapter that subscribes to topics and writes points into the Data Archive; the AVEVA roadmap lists an MQTT adapter among its adapters. Cognite’s route is a hosted extractor: Cognite’s documentation describes sources (MQTT brokers, Kafka brokers, Azure Event Hubs, REST APIs), jobs that run the extraction, mappings from source data to CDF resources, and destinations. Tulip’s route depends on the use case, from its connector framework to its edge devices.

For the architecture of the namespace itself, read our unified namespace architecture guide. The relevant design rule here is that the UNS is a publishing contract, and the downstream platforms are replaceable consumers. If you let PI AF paths or CDF external IDs define your topic hierarchy, you have just rebuilt vendor lock-in in a new place.

Sizing and backpressure

Capacity planning differs by platform. For PI, the licensed unit is the tag count, and the real load is event rate per second against the Data Archive plus AF analytics. For CDF, cost and throughput follow the volume of datapoints, the transformation compute and the API calls from consumers. For Tulip, the load is stations, apps and the frequency of machine-data events pushed into apps; pushing high-rate signals into a Tulip app is almost always a mistake, because the app does not need 1 kHz.

A worked sizing illustration (illustrative numbers, not a benchmark): a line with 2,000 tags sampled at 1 Hz generates 172.8 million datapoints per day before compression. If only 15 percent of those tags carry information a model needs at that rate, publish those at 1 Hz and the rest on change or at 10 seconds. That one decision typically moves downstream cost far more than the choice of platform, and it belongs in the edge gateway, not in any of the three products.

Buffering and store-and-forward

Network outages between plant and cloud are routine. PI edge deployments and adapters have buffering features, and the roadmap mentions adapter failover; Cognite extractors generally buffer and retry, though you should test the exact behaviour for each extractor and version. Whatever you choose, run an outage drill: unplug the uplink for an hour, restore it, and check that history backfills in order and without duplicates. I have seen more production incidents from untested backfill than from any modelling mistake.

AI Readiness: Atlas AI, CONNECT and Frontline Copilots

Every vendor now ships an AI story, and they differ in where the model sits. Cognite puts agents on top of the graph, AVEVA is embedding AI into existing tools and considering model context protocol (MCP) integrations, and Tulip puts copilots and vision inside the operator workflow.

Cognite is furthest along on exposing contextual data to external agents. Its Q3 2026 release notes describe an Industrial MCP in preview that lets compliant agents, named examples being Claude and Microsoft Copilot, query the industrial knowledge graph under each user’s permissions, with usage metered separately. The same notes list an Agent Builder CLI that scores accuracy, completeness and hallucination reduction in CI, and trust features such as visible thought traces and citations that link answers to graph items. These are largely preview or private preview, so treat them as direction rather than production guarantees.

AVEVA’s May 2026 announcements, as reported, describe AI embedded into existing tools, CONNECT extensions toward Snowflake and ServiceNow, and a Flows capability for pipelines with over 800 connectors. The same report says MCP integrations and expanded AI server management are under consideration, which means they are not committed. If AI-on-contextual-data is your driver, AVEVA’s stronger path today is moving PI data into your own lakehouse, with the graph arriving on its roadmap.

Tulip’s AI is aimed at the operator: an AI chat that answers from manuals, SOPs and system data, OCR for labels, speech-to-text defect reporting and no-code vision. The page quotes percentage improvements (halved resolution time, up to 90 percent faster receiving), which are vendor marketing figures drawn from unspecified deployments. Useful as hypotheses to test in a pilot; not as planning numbers.

The architectural point about AI is that quality is bounded by context. An agent over raw tags will hallucinate relationships; an agent over a well-modelled graph can cite them. That is the strongest argument for investing in the modelling work from the previous section, and it holds regardless of which vendor you pick.

Licensing, Lock-in and Migration Paths

Licensing follows each vendor’s unit of value: tags for PI, consumption for Cognite, and stations or seats for Tulip. Vendors negotiate individually, so I give the logic and not prices, and I recommend modelling total cost for three years against your own tag count, user count and query patterns.

Pricing logic, qualitatively

AVEVA’s licensing documents describe tag-based metering. The April 2025 roadmap mentions a new aggregate tag licensing option, says PI Servers can be deployed without an additional purchase, and says tag usage is reported automatically and monitored centrally in CONNECT, with tags spreadable across multiple servers. The takeaway: tag count is the lever, so deadbanding and tag hygiene directly reduce spend. Details of current schedules are in AVEVA’s published software schedule, and I have not verified contract terms.

Cognite’s consumption orientation means costs scale with data volume, compute and increasingly with AI usage. Cognite states that Industrial MCP usage is metered separately from native Atlas AI usage, so an enterprise that lets many external agents query the graph can generate a bill that no data engineer forecast. Put a usage cap and an owner on it from day one.

Tulip’s costs scale with the footprint of the shop floor: stations, devices and app complexity. The hidden cost is app governance. A hundred well-meaning citizen developers build a hundred slightly different apps, and a validated-environment pharmaceutical plant then pays for the change control.

Where lock-in actually lives

Lock-in is rarely in the storage format. It is in the semantic layer you built. PI lock-in sits in AF templates, analytics expressions and PI Vision displays, which represent years of encoded engineering knowledge and only export painfully. CDF lock-in sits in the data model, transformations and the apps built on its APIs; the raw data is retrievable, but the context graph is the asset and it is shaped to Cognite’s resource types. Tulip lock-in sits in the apps and their logic, because there is no standard interchange format for no-code workflows.

Mitigations are the same in all three cases. Keep the namespace and the raw streams vendor-neutral (MQTT with a documented payload contract, OPC UA models), keep the asset hierarchy in a system you own (often the engineering or maintenance master), and export the semantic layer to open formats on a schedule, even if you never expect to use the export. A lock-in review should ask: how long to rebuild the context layer elsewhere, in engineer-months?

Migration paths that work

Three migrations come up repeatedly.

PI to PI plus Cognite. The most common path. Keep PI as the system of record, run Cognite’s PI extractor into CDF, import the AF hierarchy as the starting asset tree, and add documents and work orders to the graph. PI keeps serving operations; CDF serves analytics and AI. Resist the urge to retire PI, because the control-room workflows around it are the hardest part to move.

PI on-prem to PI hybrid with CONNECT. For sites that want cloud sharing without a second vendor. The PI to CONNECT agents move tag data to the cloud service, and the roadmap lists reverse flows as in development. Verify the status of the specific agents you need.

Tulip beside either. Tulip apps read machine context via connectors or the open API and write records back. Sensible integration points are batch or order context coming from the ERP or MES layer, and quality data going to the graph or lakehouse. Keep control-system writes out of Tulip unless your safety case explicitly covers it.

The path I rarely recommend is a big-bang replacement of a mature historian. If the motivation is cost, fix tag sprawl first. If it is capability, add a layer beside it.

Figure 4: A pain-first decision tree. Most mature plants end at a combination, not a single platform.

The tree encodes the central message: choose by the main pain, then ask whether a second layer is justified. In practice the “PI plus a context layer” and “CDF plus Tulip” leaves are the most common outcomes.

Scenario-Based Selection Matrix

Use this matrix after the pain-first tree. Scores are my qualitative judgements from documentation and project experience, not measurements.

Scenario	AVEVA PI	Cognite Data Fusion	Tulip
Long-term process history, compliance trending	Strong fit	Possible, not the strength	Poor fit
Cross-source context (P&ID, work orders, 3D)	Weak to moderate	Strong fit	Poor fit
Operator workflows, quality checks, kitting	Not applicable	Not applicable	Strong fit
AI agents over contextual data	Roadmap dependent	Strongest today, mostly preview	Operator-level AI
Heavy-asset enterprise (oil, gas, power)	Strong, as a base	Strong, as the context layer	Marginal
Discrete manufacturer, many sites, fast rollout	Moderate	Moderate	Strong
Regulated pharma with validated workflows	Strong for data	Possible	Strong, with governance cost
Small team, little data engineering capacity	Strong	Risky	Strong

Two readings matter. First, the right-hand column is complementary in nearly every row where the other two score weakly, which is why “versus” is the wrong framing. Second, the bottom row is the most underrated: Cognite rewards data engineering teams and punishes sites without one.

Compare this with the broader data-architecture options in UNS vs data mesh vs data fabric when the question is organisational and not just technological.

Trade-offs, Gotchas, and What Goes Wrong

The failures I see are rarely product defects. They are mismatches between the primitive and the job, and they follow a few recognisable patterns.

Using a historian as a data lake. Teams export PI data into a warehouse with a script, discover that AF context is lost in the export, and rebuild it by hand. Plan the AF-to-model mapping at the start, not after the first dashboard disappoints.

Using a graph platform as a historian. CDF can store and query time series, and its time series features are improving, but control engineers will compare it to PI on interpolation behaviour, aggregates at odd boundaries and data quality flags. If sub-second control-room trending is the requirement, keep a historian in the loop.

Treating no-code as no-governance. Tulip’s speed is real, and so is app sprawl. Without a naming convention, a review gate and a library of approved components, the first year produces a collection of apps nobody dares change. Regulated environments should treat each production app as a validated configuration item.

Contextualisation optimism. Entity matching and automated P&ID parsing can handle a large fraction of clean documents, but old scans, inconsistent tag naming and unmaintained hierarchies drop the match rate. Budget manual review time and measure precision on a sample, as described earlier.

Roadmap purchasing. Several items in this comparison are preview or roadmap: Cognite’s Industrial MCP, state time series and sandboxes are in preview; AVEVA’s knowledge graph, MCP integrations and some hybrid flows are planned. Contract for what is generally available, and treat preview features as a free option, not a dependency.

Security and write-back. Any platform with write-back to controllers or to PI tags extends the attack surface. Segment networks per the Purdue-style model, keep write paths narrow and audited, and prefer one-way data diodes or brokers at the OT boundary for analytics flows. Agents with tool access deserve the same scrutiny as people with credentials; Cognite’s per-user permission model for MCP is the right idea, and still needs testing against your own access policies.

Cost surprises. Tag-based licensing punishes tag sprawl; consumption pricing punishes unbounded queries and AI usage; seat-based pricing punishes broad rollouts without value tracking. Each has a different monitoring need, and finance should hear about all three before signature.

People risk. PI skills are widespread among OT engineers. Graph modelling and Python transformation skills sit in a different team. Tulip app building sits in operations. A cross-functional owner for the data contract between these groups is not optional.

Practical Recommendations

Start from the question your plant asks daily and the team you actually have. If it is trend analysis and compliance, keep or adopt PI and spend on tag hygiene and AF templates. If it is root-cause analysis across documents, work orders and sensors, or AI agents that cite evidence, add a context layer such as CDF beside the historian. If it is operator execution, add Tulip for the workflows and feed its records into the shared data layer.

Sequence the work. First, stand up a vendor-neutral UNS and edge gateway with sensible publish rates. Second, choose the system of record for each domain: tags, assets, work orders, operator records. Third, build one end-to-end use case on a single line, measure it, and only then scale. Fourth, document the exit: how you would rebuild the semantic layer elsewhere.

For a proof of concept, set pass criteria in advance: match rate of tags to assets, query latency for the traversal your engineers run daily, backfill correctness after an outage, time for a non-developer to change an operator workflow, and a cost projection at 3x the data volume.

Checklist before you sign

• Name the primary unit of value (tags, graph nodes, stations) and confirm the pricing metric matches it.
• Confirm which features you rely on are generally available, not preview or roadmap.
• Keep the UNS topic structure vendor-neutral and documented.
• Run an outage and backfill drill during the pilot.
• Measure asset-matching precision on 200 real tags.
• Cap and assign an owner to consumption and AI usage costs.
• Export the semantic layer (asset hierarchy, templates, views) to open formats on a schedule.
• Define governance for no-code apps before the first production release.
• Segment write-back paths and audit them.
• Assign one owner for the cross-platform data contract.

Frequently Asked Questions

Is AVEVA PI a competitor to Cognite Data Fusion?

Partly. Both ingest plant time series, but PI is a historian with an asset layer, and CDF is a knowledge graph with a time series component. Many operators run both: PI as the operational system of record and CDF as the contextualisation and analytics layer. Cognite ships a PI extractor for exactly this reason. They compete for the same budget more than for the same job, and AVEVA’s roadmap for a CONNECT knowledge graph will increase direct overlap from 2027.

Can Tulip replace a historian or an MES?

Tulip does not replace a plant historian, because it is not built to retain high-rate tag data for years. It positions itself as a composable MES, and Gartner’s 2025 Market Guide for Manufacturing Execution Systems included it, according to Tulip’s own announcement. Whether it can replace your MES depends on your regulatory, scheduling and integration needs. For discrete and regulated assembly, many sites use it as the execution layer beside a historian.

Which is cheapest: PI, Cognite or Tulip?

There is no honest single answer because they meter different things. PI costs track tag counts, Cognite’s track data volume, compute and AI usage, and Tulip’s track stations and devices. A small plant with a few thousand tags can find PI economical, while a multi-site enterprise doing heavy analytics may find consumption costs dominate. Model three years against your own volumes and ask each vendor for written assumptions; do not rely on public list figures, which mostly do not exist.

Do these platforms support OPC UA and MQTT?

Yes, with different shapes. PI uses AVEVA Adapters, and the 2025 roadmap lists OPC UA and MQTT among them. Cognite offers an OPC UA extractor and hosted extractors for MQTT, Kafka, REST and Azure Event Hubs. Tulip connects through its edge devices, connector framework and open API. The best practice is an edge gateway and an MQTT broker as a neutral Unified Namespace, with each platform subscribing rather than owning the topic tree.

Is Cognite’s Industrial MCP ready for production?

According to Cognite’s Q3 2026 release notes it is a preview, so it is not generally available at the time of writing. It lets compliant agents such as Claude or Microsoft Copilot query the knowledge graph under each user’s permissions, with separate metering. Pilot it on read-only, low-risk questions, test your permission model with deliberately unauthorised queries, and set usage caps before inviting wider use.

Should I migrate off PI to Cognite?

Usually not. Replacing a mature historian is high risk and low reward, since the real value of PI sits in embedded operational workflows. The more common and safer path is to keep PI for operations and trending and add Cognite as a context layer for cross-source analysis and AI. Revisit the question if your PI estate is cost-driven by tag sprawl, which is better solved by cleanup than by migration.

Further Reading

• SCADA vs OPC vs IoT platform vs data historian for layering of the OT data stack.
• Unified namespace architecture for industrial IoT for the neutral integration pattern.
• AVEVA and Snowflake IT/OT data architecture for industrial AI for the PI-to-lakehouse path.
• OPC UA historian to digital twin ingestion architecture for southbound ingestion detail.
• Cognite Q3 2026 product release notes and Cognite hosted extractors documentation as primary sources.
• Tulip AI-powered MES overview for the vendor’s own feature descriptions.

By Riju — about