Limitations and Non-Suitability

This page collects what the platform cannot do: the workloads that do not fit, features it does not have, and properties that are not yet true of every engine. Protocol and engine-level limits are tabulated in Cloud Engine, call latency and message sizes in Interfaces and Identity.

Not suitable

Latency-sensitive control. An update call takes about two seconds, and that floor comes from consensus. Machine control, interactive real-time systems and anything with a sub-second write requirement do not belong here.

High write throughput. Every write executes on every node. Write capacity does not improve by adding nodes — adding nodes improves read capacity and resilience only. Beyond one engine’s capacity, scaling writes requires splitting the application across canisters, which is expensive to retrofit.

Non-deterministic computation. Anything whose result differs between machines cannot execute in replicated mode. This rules out most conventional machine-learning inference.

Bulk state rewrites. Only about a third of a canister’s RAM may be modified in one execution round, because a larger round cannot be checkpointed in time. A routine that rewrites an entire large dataset in a single call will not complete. This surfaces at production data volumes, not during development against a test set.

Workloads requiring confidentiality from the operator of a shared node. Where several engines share a physical machine, memory encryption is not yet available and that machine’s provider can read canister state. Such a workload needs an engine that occupies whole nodes, where memory encryption is enabled today — see Trust and Security Model.

Absent features

Features common on enterprise platforms that a Cloud Engine does not have:

Expected	Reality
SQL or an analytical query interface	None externally. Data is reached through canister methods the application defines; SQL inside a canister is possible with a third-party crate — see Integration Patterns
Platform-level role-based access control	None for application access. Authorisation is application logic; role-based control exists for deployment
Corporate directory integration	None. Identity is a key-derived principal; mapping is the integrator’s work
Transactions spanning the engine and an external database	None
Differently sized engines on one physical node	Not supported. A node carries engines of one size at a time
Arbitrary outbound networking	Only HTTPS outcalls, subject to the determinism constraint
Engine-to-engine calls	Not yet rolled out on Cloud Engines

Status-dependent claims

Three properties frequently associated with this platform are not uniformly true today.

Property	Status today
Memory encryption, so node operators cannot read data in use	Depends on placement. Enabled for an engine alone on its node; not yet available where engines share one — see Trust and Security Model
Inter-node traffic remains within Swiss borders	Not guaranteed yet. Nodes are in Switzerland; the network path between them is not constrained to Swiss territory — see Data Storage and Locations
Engines can call one another	Not rolled out yet — see Integration Patterns

Planned

Stated as intention, not commitment.

• Engine-to-engine messaging. Whitelisted engines calling each other, which is what makes horizontal scaling across engines real.
• A separate registry for Cloud Engines. Engine creation without a dependency on the public ICP system subnets.
• Chain-key signing within an engine, without relying on ICP mainnet.
• Higher capacity per engine. Optimised safety checkpointing is expected to increase replicated storage substantially on the same hardware. Separately, the share of a node’s physical disk usable by an engine — around 10% today — is being improved on the DFINITY side, which yields more storage from hardware already deployed.
• SEV memory encryption for several engines sharing one node, so that placement stops determining whether the node’s operator can read data in use.
• Inter-node traffic constrained to Swiss territory.