Recovering an Apache Polaris deployment means recovering two independent things: the metastore database holding catalogs, grants and policies, and the object storage holding Iceberg data and metadata. They fail separately, they are backed up separately, and restoring them out of order produces a catalog that points at files that are not there.
Most disaster recovery plans for a lakehouse cover the data. The data is usually the easy part, because object storage is already replicated and Iceberg metadata is immutable. The part that gets missed is that losing the catalog loses every grant, every principal, every policy and the pointer to which metadata file is current for every table.
Files without a catalog are a directory of Parquet. This covers what to protect, how to restore it, and the order that matters.
Polaris itself is stateless. Everything that would hurt to lose is in one of two places.
A database holding Polaris entities: catalogs, namespaces, tables and views, principals, principal roles, catalog roles, grant records and policies. Crucially it also holds the current metadata pointer for every Iceberg table, which is the thing that makes a table a table.
Object storage holding Iceberg metadata JSON, manifest lists, manifests, and the Parquet data files. This is almost entirely immutable. Files are added and eventually removed by expiry and cleanup, but existing files are never edited.
The asymmetry matters. Storage is append-mostly and usually already has versioning and cross-region replication available. The metastore is a live transactional database, it changes on every commit, and it is the one with a real recovery point objective.
Polaris supports several persistence backends, and the choice determines the whole backup story.
in-memory test only lost on restart, never for production
relational-jdbc ready to use PostgreSQL or CockroachDB, recommended
nosql (MongoDB) experimental beta
nosql (DynamoDB) experimentalFor production this is PostgreSQL in practice, which is good news for recovery: the backup problem becomes an ordinary PostgreSQL backup problem with decades of tooling behind it.
Two details are easy to miss. Polaris stores its tables in a schema named POLARIS_SCHEMA by default, selected through the JDBC driver's currentSchema property. And Polaris does not create that schema. It must exist before bootstrapping, which makes schema creation a database administration step in any restore runbook rather than something the application handles. Running Polaris in production covers the deployment side.
A realm is Polaris's logical partition for multi-tenancy. Each realm has its own catalogs, principals and grants, isolated from every other. Realms and tenant isolation covers the model.
For recovery the important property is structural: the realm identifier is part of the primary key in the JDBC persistence layer. Realm data is interleaved in the same tables rather than separated into its own database.
That has a direct consequence. A plain database restore brings back every realm together. Restoring one realm to an earlier point while leaving others current is not a database-level operation, and anyone whose DR plan assumes per-tenant rollback should test that assumption before they need it.
Some deployments give each realm its own database, which the configuration supports through a realm-templated connection string. That turns per-realm recovery into an ordinary restore, at the cost of running more databases.
jdbc:postgresql://localhost:5432/{realm}Point-in-time recovery is what you want, not nightly dumps. Every Iceberg commit updates the metadata pointer, so a backup from midnight means every table reverts to its midnight state while storage still holds everything written since. Managed PostgreSQL services provide continuous archiving, and it should be switched on.
A periodic logical dump is still worth keeping alongside it. It protects against the failure modes continuous archiving does not: an accidental mass delete, a bad migration, corruption that replicates faithfully to the standby.
Object versioning on the bucket protects against accidental deletion, including an overly aggressive orphan file cleanup. Cross-region replication protects against losing a region. Both are storage features rather than Polaris features.
Be deliberate about lifecycle rules here. A rule that transitions objects to a cold tier or expires them does not know which Iceberg files are still referenced, and the catalog it would need to ask is the other system.
Root principal credentials are created at bootstrap and are not recoverable from the database in usable form afterwards. They belong in a secret manager. A restore where nobody can authenticate as root is a restore that has not finished.
The order is the part that goes wrong.
Do not run bootstrap against a restored realm expecting it to repair anything. Bootstrap is for initialising a realm that does not exist. It is idempotent, and running it against an already-bootstrapped realm has no effect, which means it will neither help nor warn you.
Be equally careful with the admin tool's other command. purge removes realms and all associated entities. It is the correct tool for decommissioning a tenant and a catastrophe to run during a recovery.
Backups of two systems taken at different moments produce a catalog and a storage layer that disagree.
Catalog older than storage. The usual case. Tables revert to an earlier snapshot while storage still holds every file written since. Nothing is broken, the newer files are simply unreferenced and will look like orphans. Recent commits are lost and have to be replayed. This is the recoverable direction.
Catalog newer than storage. The dangerous one. The catalog points at metadata and data files that the restored storage does not contain, and affected tables fail to load. Recovery means rolling those tables back to a snapshot whose files still exist, table by table.
Which is why the restore order above puts storage first. Being slightly behind on the catalog is an inconvenience. Being ahead of storage is an outage.
Not every incident needs a full restore. Most do not.
A bad write is an Iceberg rollback. The previous snapshot is still in the table's metadata and still referenced, so moving back to it is a commit rather than a restore. This works as long as the snapshot has not been expired, which is the real argument for a retention window longer than your detection time.
A dropped table is a catalog entity problem, not a data problem. The files are usually still in storage. If you have the last metadata location, the table can be registered back into the catalog without moving any data.
Relocating a table to new storage has a dedicated Iceberg procedure. rewrite_table_path stages a copy of the metadata with every absolute path prefix replaced, which is the starting point for copying a table to a different bucket or region. It rewrites metadata and produces a file list, and does not copy the data files itself.
CALL catalog.system.rewrite_table_path(
table => 'db.events',
source_prefix => 's3://old-bucket/warehouse/db/events',
target_prefix => 's3://new-bucket/warehouse/db/events');A DR plan nobody has executed is a document, not a capability. Three exercises are worth running on a schedule.
Dremio co-created Apache Polaris and donated it to the Apache Software Foundation, and Dremio’s Open Catalog is a managed Polaris implementation. The practical difference for recovery is that the metastore becomes someone else's operational responsibility, with backup and point-in-time recovery handled as part of the service.
The storage side does not change, and neither does the discipline. Object versioning, careful lifecycle rules and a retention window longer than your detection time are your responsibility whoever runs the catalog.
Pick your production Polaris deployment and answer two things. What is the recovery point for the metastore, in minutes rather than in principle? And has anyone restored it and loaded a table?
If the first answer is a nightly dump and the second is no, the gap between your assumed and actual recovery is probably measured in hours. The Polaris architecture explains what is in the metastore and why losing it costs more than losing a day of writes.
Two things. The metastore database, which holds catalogs, principals, grants, policies and the current metadata pointer for every table. And the object storage holding Iceberg metadata and data files. Backing up only one leaves you unable to recover.
For production, PostgreSQL or CockroachDB through the relational JDBC backend. MongoDB and DynamoDB backends exist but are experimental. The in-memory backend loses everything on restart and is for testing only.
Not from a shared database. The realm identifier is part of the primary key, so realm data is interleaved and a restore brings back all realms together. Giving each realm its own database, using a realm-templated connection string, makes per-realm recovery possible.
Storage first, or confirm it is intact. A catalog restored ahead of storage points at files that do not exist and those tables fail to load. A catalog slightly behind storage only leaves unreferenced files, which is recoverable.
No. Bootstrap initialises a realm that does not exist and is idempotent, so running it against an existing realm has no effect at all. It will not repair anything and will not warn you.
Roll the table back to its previous snapshot, which is a commit rather than a restore and needs no backup. This only works while that snapshot has not been expired, which is why the retention window should exceed the time it takes your team to notice a problem.
Yes, using the rewrite_table_path procedure. It stages a copy of the table metadata with every absolute path prefix replaced and produces a list of files to copy. It rewrites metadata only and does not move the data files for you.
For a full treatment of the catalog layer, download Apache Polaris: The Definitive Guide by Alex Merced, Andrew Madson, and Tomer Shiran, free from Dremio.
To see these ideas applied in practice, explore Dremio’s Open Catalog, built on Apache Polaris.
Deploy agentic analytics directly on Apache Iceberg data with no pipelines and no added overhead.
Editor’s note, September 2026. This post was published in September 2023 and some product details have changed since. Nessie is still available and self-deployable under the Apache-2.0 licence, and it remains the clearest implementation of catalog-level branching. It is not an Apache Software Foundation project, and its development has slowed considerably. For how the current […]
With its capabilities in on-prem to cloud migration, data warehouse offload, data virtualization, upgrading data lakes and lakehouses, and building customer-facing analytics applications, Dremio provides the tools and functionalities to streamline operations and unlock the full potential of data assets.
Apache Iceberg 1.12.0 expands v3 engine support, REST catalog operations, streaming reliability, and v4 groundwork. Learn how to upgrade safely.