iModel States

[candcconsulting]

Can someone from Bentley advise if the below is accurate ... and if not advise of iModel states ?

iModel States

Cold iModel State

A Cold iModel refers to a state where the digital twin data resides strictly in cloud storage (like Azure Blob) and has not yet been opened, provisioned, or copy into active memory/local SSD storage by the backend execution nodes.

• ECSQL Performance: Very Slow (High Latency).
• What happens under the hood: When an ECSQL query is fired against a cold iModel, the infrastructure must first provision a container/backend worker, copy the required briefcase (.bim file) or pull the required change-sets, and mount the database.
• Impact: The initial query experiences a significant "cold start" delay, sometimes taking seconds or even minutes depending on the size of the infrastructure asset.

Cached (Warm) iModel State

A Cached (or Warm) iModel means that the physical database file has already been copied to the backend worker's local SSD storage, or the schema has been parsed, but it isn’t actively kept alive in the system's ultra-fast RAM.

• ECSQL Performance: Moderate to Fast.
• What happens under the hood: The database connection is closed or idling, but because the files are already locally cached on the host machine, it avoids the heavy cloud provisioning phase. When the ECSQL runs, SQLite opens the local to the worker file quickly.
• Impact: Performance is dramatically better than a cold state. However, the very first ECSQL query on a cached iModel will still experience minor disk I/O latency as SQLite populates its internal page cache from the local SSD into memory.

Hot iModel State

A Hot iModel represents the peak performance state. In this phase, the iModel is fully opened, active backend workers are actively running, and the necessary database pages, schemas, and frequently hit indices are fully loaded into the RAM of the execution node.

• ECSQL Performance: Optimal / Near Real-Time.
• What happens under the hood: The infrastructure keeps the iModel "warm and ready" in memory. Furthermore, if you are reusing Preprepared ECSQL Statements (ECSqlStatement), the costly process of parsing the ECSQL, mapping BIS classes to raw SQLite tables, and generating query execution plans is already finished.
• Impact: ECSQL queries return results in milliseconds. This state is critical for user-facing interactive dashboards, PowerBI integrations, and real-time model analysis.

iModel Cached Query

When a query for an iModel and Change state is initially ran then the results are stored in a performance cache. The second time the query is ran with the same finderprint, the results are returned from the cache rather than running the query against the hot iModel.

• ECSQL Performance: Not applicable, ecSQL is not executed.
• What happens under the hood: The query is hashed and the results of the hash are returned from an optimal cache. Large results are returned almost instantly and are accessible instantly.
• Impact: Large datasets are returned almost instantly, when the a query is re-ran. For dhasboards accessed by many users when an iModel is only being updated daily or weekly the performance hit is only taken by the first user.