Product: Semarchy NativeApp
Version: 2025.1.12 and higher
Author: Clément Darras, Thomas Wyrick, Hélène Zosym
Need
Semarchy Native Apps run on Snowflake and can be deployed with different persistence architectures for the "data location" (business data) and the "repository" (application metadata). SRE teams need a clear view of which disaster recovery (DR), business continuity (BC), and failover capabilities Snowflake provides natively for each architecture, where those platform capabilities stop, and what Semarchy's reference backup/restore architecture adds on top to close the gap.
Two persistence patterns exist.
Summarized Solution
- Pattern II (Snowflake Postgres for both the data location and the repository) is the recommended architecture. It consolidates both stateful domains onto a component with documented HA, PITR forks, and read replicas, and avoids hybrid tables' current lack of native replication and failover.
- A complete backup/DR strategy must always cover two things: the repository (operational metadata — models, workflows, jobs, connections, security, run history) and the data location(s) (the business data itself). Losing either one leaves the application non-functional or empty, even if the other survives.
- Snowflake provides no native, end-to-end regional DR, business continuity, or failover for the full Native App stack in any pattern — the data location, the repository, and the xDM runtime must be treated as separate recovery domains with different restore procedures.
- Hybrid tables have no native replication or Fail-safe and are excluded from Snowflake backups; their only documented recovery path is
CLONEat database scope. ⚠️ This is treated as a temporary condition — Semarchy's export/restore mitigation (§6) exists specifically to cover this gap until Snowflake documents native replication/failover for hybrid tables. - Snowflake Postgres (Managed PostgreSQL) offers stronger native protection — automatic HA with standby promotion, PITR forks, and read replicas — but still has no cross-region failover comparable to account failover groups, so cross-region DR still requires a backup/restore mitigation, just a simpler one (§7).
- The xDM runtime is a stateful, single-instance SPCS service in every pattern; the only native continuity behavior is restart or recreation of that one instance — never load-balanced or zero-downtime failover.
- Two reference architectures are provided: an interim architecture (Hybrid Tables + Managed Postgres repository, §6) for customers who have not yet migrated their data location, and the recommended target architecture (Pattern II, §7) for customers who have consolidated everything onto Snowflake Postgres.
This article combines the internal SRE operational reference for xDM Snowflake Native Apps with Semarchy's reference backup and disaster-recovery architectures to describe the end-to-end strategy: what needs to be backed up, what is documented as available on the platform, what is not, and the concrete backup/restore workflow used to recover a Native App after a regional loss — for both the current interim architecture and the recommended target architecture.
| Term | How it is used in this article |
|---|---|
| Disaster recovery | Restore data and service after corruption, accidental deletion, or loss of the primary environment. |
| Business continuity | Keep the service running inside the same region during host, placement-group, or maintenance events. |
| Failover | Switch traffic or workload to another healthy host, instance, or environment with minimal interruption. |
Detailed Solution
1. Architecture Patterns in Scope
| Pattern | Data location | Repository | xDM runtime | Status |
|---|---|---|---|---|
| Pattern I | Hybrid Tables (Snowflake) | PostgreSQL container on SPCS block storage | Single-instance SPCS container | Legacy |
| Interim architecture | Hybrid Tables (Snowflake) | Snowflake Postgres (Managed), replica in DR region | Single-instance SPCS container, pre-installed in DR region | Transitional — repository migrated, data location not yet migrated |
| Pattern II | Snowflake Postgres | Snowflake Postgres (same instance) | Single-instance SPCS container | Recommended target |
Semarchy recommends Pattern II as the target state for new and migrated deployments. Consolidating both the data location and the repository onto Snowflake Postgres removes hybrid tables' lack of native replication and failover from the equation entirely, and gives SRE teams a single, better-protected component (HA, PITR, read replicas) instead of two components with very different native guarantees. The interim architecture — repository already migrated to Managed Postgres, data location still on hybrid tables — remains a valid stepping stone (see the companion repository migration guide), but should be treated as transitional, not a long-term target, since hybrid tables still lack native regional protection.
Regional planning note: hybrid tables are documented by Snowflake as available only in AWS and Azure commercial regions; Snowflake Native Apps with containers also require supported commercial regions. Snowflake Postgres is likewise documented on AWS and Azure only. Any primary/secondary site plan must stay within these supported regions for every layer involved.
2. What Needs to Be Backed Up in a Native App
Regardless of which pattern is deployed, a Native App has exactly two stateful domains that must both be protected. Missing either one makes the recovered application unusable:
| Component | Contains | Stored in (Pattern I / interim) | Stored in (Pattern II — recommended) |
|---|---|---|---|
| Repository | Operational metadata: data models, workflow and job definitions, connections, security/role grants, scheduling configuration, image libraries | PostgreSQL container on block storage, or Snowflake Postgres | Snowflake Postgres (same instance as the data location) |
| Data location(s) | Business data: the master, transactional, and reference data managed by the app | Hybrid Tables | Snowflake Postgres (same instance as the repository) |
- Repository content is what lets the Native App know how to behave — without it, the app has no configuration, no workflows, and no orchestration state, even if all the business data is intact.
- Data location content is what the app operates on — without it, the app can start and run, but has no business data to serve.
A backup/DR strategy is only complete when both domains are captured on a schedule that matches the required RPO, and both can be restored together into a consistent state (see §6 and §7 for the concrete workflows).
3. Disaster Recovery — Native Snowflake Capabilities
| Layer | What Snowflake documents as available | What Snowflake does not provide natively | SRE operating position |
|---|---|---|---|
| Data location — Hybrid Tables | Point-in-time recovery by cloning the containing database at a chosen time (CLONE), documented at database scope only, not schema or table scope. | No replication, no Fail-safe; hybrid tables are excluded from Snowflake backups. | Business data in hybrid tables has no platform-managed regional recovery path — it must be exported and restored explicitly (see §6). |
| Repository — PostgreSQL container on block storage (Pattern I) | Block-volume snapshots, restoration of an existing service volume, initialization of a new service from a snapshot, and UNDROP SNAPSHOT within the retention window. | No managed cross-region failover or replication for block volumes; SPCS services, compute pools, and image repositories are excluded from Snowflake backups and from failover-group object types. | Treat as a restore-from-snapshot procedure, not a promote-secondary architecture. |
| Repository / consolidated instance — Snowflake Postgres (interim repository, and Pattern II) | Recovery from the most recent automated backup plus WAL replay if HA is not enabled; PITR forks (a full, independent copy of the instance) within the retention window; in Pattern II, state consolidation means one recovery event covers both domains at once. | Snowflake Postgres instances are not covered by failover groups or backup sets; no managed cross-region failover feature comparable to failover groups. | The practical DR controls are host recovery, optional HA, and PITR forks — still not a full regional DR control plane for the whole application. |
| xDM runtime | The SPCS runtime can be re-created from its service specification and images. | No platform-managed DR restore for the full application stack; Native Apps do not support failover for business continuity. | Runtime redeployment is a redeploy-and-reconnect step, not an automatic recovery. |
Temporary mitigation. Hybrid tables currently have no native replication, Fail-safe, or backup coverage, and Snowflake has not documented a native regional DR or failover mechanism for them. The export/restore workflow in §6 is a temporary mitigation Semarchy provides to cover this gap while the data location remains on hybrid tables. Migrating the data location to Snowflake Postgres (Pattern II, §7) removes the dependency on this mitigation entirely and is the recommended path for customers who need full native protection in short terme. In longer term, Snowflake intends to provide native replication/failover mechanism for Hybrid Tables.
4. Business Continuity — Native Snowflake Capabilities
| Layer | What Snowflake documents as available | What Snowflake does not provide natively | SRE operating position |
|---|---|---|---|
| xDM runtime (all patterns) | SPCS restarts a stopped container; with placement_group = DISTRIBUTED, Snowflake relocates or recreates the impacted instance on a healthy placement group during an outage. | Zero-downtime continuity — a single-instance service is disrupted while Snowflake recreates it; no automatic failover to healthy placement groups beyond recreation. | Because xDM is intentionally single-instance, same-region continuity is restart-based, not seamless. |
| Repository — container on block storage (Pattern I) | Block storage is preserved across suspend/resume and service upgrade; snapshots are the documented protection mechanism (data is removed when the service is dropped). | Scale-out is not possible (MIN_INSTANCES must equal MAX_INSTANCES and cannot later change); volumes are not shared across service instances. | Repository remains a single-instance stateful service — no multi-instance active/active model is documented. |
| Repository / consolidated instance — Snowflake Postgres (interim repository, and Pattern II — recommended) | With HIGH_AVAILABILITY = TRUE, Snowflake provisions a standby in a separate availability zone, replays writes, and automatically promotes the standby if the primary is lost — with no connection-detail change required. Read replicas are available for read offload. | HA is not supported on burstable instance sizes (BURST_XS, BURST_S, BURST_M); read replicas are read-only and not documented as promotable failover targets. | The central same-region continuity control is Snowflake Postgres HA on a non-burst instance class — this is the strongest native BC control available in either pattern, another reason Pattern II is recommended. |
5. Failover — Native Snowflake Capabilities
| Layer | What Snowflake documents as available | What Snowflake does not provide natively | SRE operating position |
|---|---|---|---|
| xDM runtime (all patterns) | Restart of a stopped container and recreation of an impacted service instance on healthy compute capacity. | No parallel xDM instance, so there is no load-balanced failover across instances. | Intra-region recovery is restart-based, not failover between parallel instances. |
| Repository — container on block storage (Pattern I) | Restore the block volume from a snapshot, or seed a new service from a snapshot. | Not replica promotion — recovery is from storage artifacts only. | Plan for a restore, not a live cutover. |
| Repository / consolidated instance — Snowflake Postgres (interim repository, and Pattern II) | Automatic host/AZ failover with HA enabled, using the same connection details; manual cutover to a PITR fork (a new instance) for logical rollback or corruption recovery. | No managed cross-region failover comparable to account failover groups. | Automatic failover exists only within a region when HA is enabled. |
| Whole application stack | — | No documented Snowflake-native failover chain spans the xDM runtime, the repository, and the data location together; Native Apps do not support failover for business continuity; hybrid tables have no replication, so a hybrid-tables data location has no native regional failover path. | Regional failover for the full application is a redeploy-plus-restore procedure in every pattern, and a secondary environment should be pre-staged and tested as a restore target — never assumed to be a Snowflake-native promoted secondary. |
6. Reference Architecture — Interim State (Hybrid Tables + Managed Postgres Repository)
This architecture applies to customers who have migrated the repository to Snowflake Postgres but whose data location is still on hybrid tables. It should be treated as a temporary step, not a long-term target — see the warning in §3.
Production region
- The Semarchy Native App runs in the Snowflake PROD account, reading and writing business data in Hybrid Tables and application metadata in a Snowflake PostgreSQL primary writer (the repository).
- Hybrid table contents are periodically copied into standard Snowflake backup tables, then unloaded to a Parquet export stage.
Backup layer (cross-region object storage)
- The Parquet export stage is pushed to cross-region object storage (S3 / Azure Blob), split into three backup sets: metadata backups, Parquet data backups, and security backups.
- The Snowflake Postgres repository is protected independently through a read-replica kept in the DR region.
DR region
- The Snowflake DR account holds a pre-installed (but idle) copy of the Semarchy Native App and empty DR hybrid tables as the data location, ready to be populated from the object-storage backups during a restore.
- The Snowflake Postgres read-replica provides an up-to-date, standby copy of the repository in the DR region.
- On activation, the restore process rehydrates the empty DR hybrid tables from the object-storage backups and brings the app to an operational DR environment.
Backup design tiers
| Design tier | Repository protection | Hybrid table backup frequency | RPO | RTO |
|---|---|---|---|---|
| Basic | PostgreSQL HA / PITR | Nightly export | 24 hrs | 6–12 hrs |
| Recommended | PostgreSQL HA / PITR | Hourly export | 1 hr | 2–6 hrs |
| Premium | PostgreSQL HA / PITR | 15-minute export | 15 min | 1–4 hrs |
Disaster recovery runbook
- Declare Disaster — confirm loss of the production environment and formally trigger the DR procedure.
- Activate DR Native App — bring the pre-installed Native App in the Snowflake DR account online.
- Restore Databases — restore the hybrid table data location in the DR region from the Parquet data backups in cross-region object storage, and make the Snowflake Postgres read-replica available as the active repository.
- Import Metadata — load the metadata backups from object storage into the restored environment.
- Rebuild Runtime State — reconstruct the xDM runtime's operating state (recreating the single-instance SPCS service) against the restored data location and repository.
- Validate — verify data integrity and application behavior in the DR environment before cutover.
- DNS Cutover — redirect traffic/DNS to the operational DR environment, completing the failover.
7. Reference Architecture — Pattern II (Recommended Target State)
This is the recommended architecture for new deployments and the migration target for existing ones: both the data location and the repository are consolidated in a single Snowflake Postgres instance.
Production region
- The Semarchy Native App runs in the Snowflake PROD account against a single Snowflake Postgres instance with
HIGH_AVAILABILITY = TRUE, hosting both the repository (operational metadata) and the data location (business data). - Snowflake automatically provisions a standby in a separate availability zone, replaying writes and promoting the standby if the primary host is lost — protecting against AZ/host failure inside the region, with no connection-detail change required.
- Automated backups and WAL archiving are retained for PITR forks within the retention window, covering logical corruption or operator error inside the region.
Backup layer (cross-region object storage)
- Snowflake Postgres does not provide native cross-region replication or failover, so cross-region DR still requires a backup/restore mitigation — but a simpler one than the interim architecture, because both domains live in one instance. A single scheduled export (dump) of the Postgres instance — covering the repository and the data location together — is pushed to cross-region object storage (S3 / Azure Blob), using the same backup-and-export mechanism as a repository migration (see the companion repository migration guide).
- Because there is only one component to protect, there is no need to split backups into separate metadata/data/security sets as in the interim architecture — one consistent export captures the full application state.
DR region
- The Snowflake DR account holds a pre-installed (but idle) copy of the Semarchy Native App.
- A Snowflake Postgres instance in the DR region is restored from the latest cross-region export at activation time — either created fresh at disaster time, or pre-provisioned and periodically refreshed to reduce RTO.
- Because state is consolidated, a single restore operation recovers both the operational metadata and the business data together.
Backup design tiers
| Design tier | Cross-region export frequency | RPO | RTO |
|---|---|---|---|
| Basic | Nightly export | 24 hrs | 4–8 hrs |
| Recommended | Hourly export | 1 hr | 1–4 hrs |
| Premium | 15-minute export (or continuous WAL shipping to cross-region storage) | 15 min | 30 min–2 hrs |
RTO is generally lower than the interim architecture at every tier, since only one system needs to be restored instead of two.
Disaster recovery runbook
- Declare Disaster — confirm loss of the production environment and formally trigger the DR procedure.
- Activate DR Native App — bring the pre-installed Native App in the Snowflake DR account online.
- Restore Postgres Instance — restore the DR-region Snowflake Postgres instance from the latest cross-region export; because the repository and the data location share one instance, a single restore recovers both together.
- Rebuild Runtime State — reconstruct the xDM runtime's operating state (recreating the single-instance SPCS service) against the restored instance.
- Validate — verify data integrity and application behavior in the DR environment before cutover.
- DNS Cutover — redirect traffic/DNS to the operational DR environment, completing the failover.
Best Practices Summary
- ✅ Adopt Pattern II (Snowflake Postgres for both the data location and the repository) as the target architecture — it provides native HA, PITR, and read replicas that hybrid tables lack, and simplifies backup/restore to a single component.
- ✅ Back up both the repository (operational metadata) and the data location(s) (business data) on every cycle — a strategy that omits either one is incomplete.
- ✅ Use Snowflake Postgres with HIGH_AVAILABILITY = TRUE on a non-burst instance class for same-region continuity, in either the interim or the recommended architecture.
- ✅ Export data to cross-region object storage on a schedule matching the customer's required RPO (nightly, hourly, or 15-minute, per tier), for whichever component(s) lack native cross-region protection.
- ✅ Pre-install the Native App and keep an idle DR-region environment ready to activate.
- ✅ Validate the DR environment before DNS cutover — never cut traffic over before integrity checks pass.
- ✅ Confirm every layer (hybrid tables, Native Apps with containers, Snowflake Postgres) is deployed only in Snowflake's supported commercial regions (AWS and Azure).
- ❌ Never assume Native Apps support failover for business continuity — Snowflake documents that they do not.
- ❌ Never treat the hybrid-table export/restore mitigation as a permanent architecture — it exists only until the data location is migrated to Snowflake Postgres, or until Snowflake documents native replication/failover for hybrid tables.
- ❌ Never treat Snowflake Postgres read replicas as failover targets — they are documented as read-only scaling objects, not promotable replicas.
- ❌ Never expect zero-downtime continuity from the xDM runtime — it is intentionally single-instance, so recovery is always restart- or recreation-based.
Following this strategy gives SRE teams a realistic recovery posture: standardize on Pattern II where possible to get the strongest native per-layer protections (Postgres HA, PITR), and use Semarchy's cross-region backup layer and DR runbooks — interim or target — to cover what the platform does not provide natively: full-stack, cross-region disaster recovery.