Skip to content

restoring-source-database.mdx

Latest commit

 

History

History
80 lines (52 loc) · 3.82 KB

restoring-source-database.mdx

File metadata and controls

80 lines (52 loc) · 3.82 KB
title Restoring your source database
description How PowerSync handles source database restores and what to expect during reprocessing

Overview

Backing up your source database does not affect PowerSync operation. However, restoring from a backup typically requires PowerSync to perform a full reprocess of the data.

This page explains what happens when you restore your source database and how to plan for it.

What happens after a database restore

When you restore your source database from a backup:

  • PowerSync's replication state may become invalid
  • The PowerSync Service will need to reprocess data from the restored database
  • The reprocessing might not happen automatically, and you may need to trigger it manually (by redeploying the sync rules or restarting the service).
  • Clients can continue syncing existing data during reprocessing, but new changes won't sync until it's complete. They may experience temporary delays.
A full reprocess can take significant time for large datasets. Plan maintenance windows accordingly when restoring source database backups.

Planning for database restores

When planning source database backup and recovery:

  1. Test restore procedures in a staging environment to understand reprocessing duration
  2. Plan maintenance windows during low-traffic periods for database restores
  3. Consider data volume when estimating recovery time - larger datasets take longer to reprocess

Factors affecting reprocessing time

  • Data volume: Total size of data in synced tables
  • Sync rules complexity: Number of tables, joins, and transformations
  • Database performance: CPU, memory, and I/O capacity

For more details on performance considerations, see Performance and Limits.

Multi-tenant considerations

For multi-tenant architectures using a shared database with tenant isolation through sync rules, you can perform tenant-specific recovery without triggering a full reprocess.

Tenant-specific recovery

Instead of restoring the entire database, restore only the affected tenant's data:

  1. Backup and restore tenant-specific data using your source database's native tools with filtering (e.g., WHERE tenant_id = X)
  2. PowerSync detects restored data as incremental changes and replicates them automatically
  3. Other tenants continue operating without interruption (assuming replication keeps pace)
Implement soft deletes for accidental deletions to avoid database-level recovery in many scenarios. See [Handling Update Conflicts](/usage/lifecycle-maintenance/handling-update-conflicts) for related patterns.

Performance considerations

Large tenant restores increase replication volume. Monitor:

  • Replication lag during restore operations using Monitoring and Alerting
  • Data volume impact - high volumes can affect all tenants if replication falls behind

Database-specific notes

Different source databases use different replication mechanisms:

  • Postgres: Logical replication slots (see Postgres Maintenance for slot management)
  • MongoDB: Change stream resume tokens
  • MySQL: Binary log positions (GTID)
  • MSSQL: Change Data Capture (CDC)

The specific behavior after a restore may vary by database type. PowerSync uses checkpoints to maintain consistency during the recovery process.

Related resources