Hot & cold tiers

The hot/cold split is how OrcheStack fits a full data stack inside a single SME-scale host without running services that aren't being used.

Definition

Every OrcheStack-managed service falls into one of three classes:

• Base — ships with the control plane. Always running. Cannot be disabled.
• Hot — pulled on configuration, stays running while enabled. Used by services that stakeholders or schedulers need to reach at any time.
• Cold — pulled on configuration, runs only when a task or an engineer's click demands it. Stops when idle.

Assignment rules

The principle is simple: services that need to respond to external traffic at any moment are hot; services that respond to triggered work are cold.

• Metabase — hot. A stakeholder might open a dashboard at any time.
• Airflow scheduler — hot. It is the clock; without it, nothing fires.
• MinIO — hot. The data lake must always be readable by downstream consumers.
• Airbyte — cold. Only runs during the ingestion window.
• dbt — cold. A CLI, not a service. Runs when Airflow triggers it.
• Great Expectations, Elementary — cold. Run after dbt finishes.
• pgAdmin — cold. Ad-hoc engineer tool, not stakeholder-facing.
• OpenMetadata — cold. Heavy (~3 GB); engineers open it to explore lineage, then close it.

Cold-service lifecycle

Cold services transition through four states: STOPPED → STARTING → RUNNING → STOPPING. Transitions are driven by three triggers:

1. Airflow DAG schedule — e.g. the nightly ETL at 02:00 starts Airbyte + workers + dbt + Elementary in sequence.
2. Dashboard manual button — e.g. "Run dbt now" or "Open pgAdmin".
3. Upstream dependency — e.g. when dbt finishes, Elementary auto-starts to record test results.

A cold service only stops when its reference-counted session count hits zero AND the idle timeout has elapsed. See Service sessions for the multi-user safety this provides.

Resource comparison