Neither Vendor Publishes a Disaster Recovery Number Worth Repeating

A 99.99% SLA figure on Snowflake's comparison page traces to an availability credit tier, not a disaster recovery commitment.

Snowflake's comparison page advertises a 99.99% SLA for disaster recovery. Read Snowflake's own legal documentation and that number describes the best available tier for missing standard uptime, not a recovery time or recovery point commitment. Databricks has not published a disaster recovery number this piece can defend. Snowflake has not either, despite its marketing claim.

What a DR claim would need to show

Not an uptime percentage. A stated recovery time objective, a stated recovery point objective, and a scope that says which tables are actually covered. Availability SLAs answer a different question than disaster recovery SLAs, and the two get merged in marketing more often than Snowflake's own documentation supports.

Dimension	Databricks	Snowflake
Product status	Public Preview, June 12, 2026	No preview label, Snowflake-managed tables only
Gating	Enterprise plan + Mission Critical add-on, both regions	Business Critical Edition (or higher) for failover groups
Failover	User-triggered, "completes in minutes," no RTO/RPO published	Async, lag "at most 2x the time interval between scheduled refreshes," no RTO/RPO published
Known gaps	Row-filter/column-mask/ABAC tables flagged "Failed to replicate"; external-engine writes may be lost on failover	Catalog-linked tables: replication and cloning "aren't supported"; only Snowflake-managed tables replicate at all
"99.99% SLA" claim	Not made	Claimed on comparison page; underlying SLA document's best tier is "under 99.99%," a credit remedy, not a guarantee, no DR/RTO/RPO mentioned anywhere in the document

What shipped, and when

Databricks Managed Disaster Recovery is Public Preview as of a June 12, 2026 release note, gated behind the Enterprise plan and the Mission Critical add-on, with user-triggered failover and no numeric recovery commitment published. Its own documentation states that tables with row filters, column masks, or ABAC tags are flagged as failed to replicate, and that writes from an external, non-Databricks engine through open APIs such as the Iceberg REST Catalog might not be detected and can be lost during failover.

Snowflake's replication covers Snowflake-managed tables only, and its catalog-linked database documentation states plainly that replication and cloning are not supported for tables linked to an external catalog. Failover groups require the Business Critical edition. Replication lag is bounded at roughly twice the scheduled refresh interval, a real, published number, and a different kind of number than an RTO or an RPO.

Snowflake's comparison page separately advertises a 99.99% SLA for disaster recovery. That figure does not correspond to a guarantee at 99.99%. The best available tier in Snowflake's own Support Policy and Service Level Agreement is triggered when availability falls under 99.99% but at or above 99.0%, paired with a 10% error rate threshold, and it pays a credit, it does not promise the number in the marketing claim. The words disaster recovery, RTO, and RPO appear nowhere in that document.

Where Snowflake wins, stated plainly

Snowflake's replication carries no preview label. Databricks Managed DR does. If the requirement is a shipped, non-preview replication feature today, Snowflake has one and Databricks does not, even though both come with real, unadvertised gaps.

The limits of this argument

This does not establish that Databricks Managed DR is production-ready outside its Preview status. It does not establish that Databricks' disaster recovery meets a specific RTO or RPO, Databricks has not published one. Snowflake has not published one either, on the pages reviewed here. It does not extend Snowflake's 99.99% figure to disaster recovery, because Snowflake's own legal documentation does not either.

The verdict

A 99.99% figure borrowed from an availability credit tier and applied to disaster recovery is not evidence of disaster recovery. It is evidence that one comparison page and one legal document were never checked against each other.

Sources

[1] Databricks release notes, June 12, 2026. https://docs.databricks.com/aws/en/release-notes/product/2026/june

[2] Databricks, "Managed disaster recovery." https://docs.databricks.com/aws/en/admin/managed-disaster-recovery

[3] Snowflake, "Iceberg table replication." https://docs.snowflake.com/en/user-guide/tables-iceberg-replication

[4] Snowflake, "Replication and failover." https://docs.snowflake.com/en/user-guide/replication-failover

[5] Snowflake, "Catalog-linked databases." https://docs.snowflake.com/en/user-guide/tables-iceberg-catalog-linked-database

[6] Snowflake, comparison page. https://www.snowflake.com/en/snowflake-vs-databricks/

[7] Snowflake, "Support Policy and Service Level Agreement." https://www.snowflake.com/en/legal/addenda/support-policy-and-service-level-agreement/