> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-mintlify-fbfa8bee.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Managed Postgres data migration

> Compare the four migration paths into ClickHouse Managed Postgres and pick the one that fits your source database and downtime requirements.

export const galaxyOnClick = eventName => () => {
  try {
    if (typeof window !== "undefined" && window.galaxy && eventName) {
      window.galaxy.track(eventName, {
        interaction: "click"
      });
    }
  } catch (e) {}
};

export const BetaBadge = ({link, galaxyTrack, galaxyEvent}) => {
  if (link) {
    return <a href={link} target="_blank" rel="noopener noreferrer" className="betaBadge" onClick={galaxyTrack && galaxyEvent ? galaxyOnClick(galaxyEvent) : undefined}>
                <Icon />
                <span>Beta</span>
            </a>;
  }
  return <div className="betaBadge">
            <Icon />
            <span>
                Beta feature. 
                <u>
                    <a href="/docs/beta-and-experimental-features#beta-features">
                        Learn more.
                    </a>
                </u>
            </span>
        </div>;
};

You can migrate to Managed Postgres through four different paths. Which one
fits depends on whether you need ongoing replication, what source you're
migrating from, and how much downtime your application can tolerate during
cutover.

| Method                                                                               | Ongoing replication (CDC) | Where it runs              | Best for                                                                 |
| ------------------------------------------------------------------------------------ | ------------------------- | -------------------------- | ------------------------------------------------------------------------ |
| [ClickPipes](/products/managed-postgres/migrations/clickpipes)                       | Yes                       | ClickHouse Cloud console   | Most migrations — guided wizard with initial load and CDC out of the box |
| [PeerDB](/products/managed-postgres/migrations/peerdb)                               | Yes                       | Self-hosted (Docker)       | Sources or workflows not covered by the ClickPipes UI                    |
| [pg\_dump and pg\_restore](/products/managed-postgres/migrations/pg_dump-pg_restore) | No                        | Your local machine         | One-time moves of small or static datasets where downtime is acceptable  |
| [Logical replication](/products/managed-postgres/migrations/logical-replication)     | Yes                       | Source and target Postgres | Direct control over native Postgres replication, no third-party tooling  |

<h2 id="clickpipes">
  ClickPipes
</h2>

[ClickPipes](/products/managed-postgres/migrations/clickpipes) is the recommended
path for most migrations. It runs entirely inside the ClickHouse Cloud console
and walks you through connecting to the source, exporting and importing the
schema, and starting an initial load with or without CDC. Pre-built source
connectors cover Amazon RDS, Aurora, Supabase, Google Cloud SQL, Azure
Flexible Server, Neon, Crunchy Bridge, TimescaleDB, and any generic Postgres
instance.

<h2 id="peerdb">
  PeerDB
</h2>

[PeerDB](/products/managed-postgres/migrations/peerdb) is a self-hosted migration
tool you run via Docker. Use it when your source or workflow isn't a fit for
the ClickPipes wizard — for example, when you need to script peer creation
across many databases or run the migration entirely inside your own network.
PeerDB doesn't migrate indexes, constraints, or triggers automatically; you
recreate those on the target after the data lands.

<h2 id="pg-dump-pg-restore">
  pg\_dump and pg\_restore
</h2>

[pg\_dump and pg\_restore](/products/managed-postgres/migrations/pg_dump-pg_restore)
take a snapshot of the source and replay it on the target. There's no ongoing
replication, so writes must stop on the source for the duration of the dump
and restore. This is the right choice for small or static datasets, or
non-production environments where a maintenance window is acceptable.

<h2 id="logical-replication">
  Logical replication
</h2>

[Logical replication](/products/managed-postgres/migrations/logical-replication)
uses native Postgres publications and subscriptions to stream changes from
the source to the target. You configure `wal_level`, replication slots, and
the `REPLICATION` privilege yourself — no third-party tooling sits in the
middle. Pick this path when you want full control over the replication
mechanics or your environment rules out external migration tools.

<h2 id="after-migration">
  After the migration
</h2>

Once data is moving, use [data validation](/products/managed-postgres/migrations/data-validation)
to confirm row counts and content match between source and target before
cutting over application traffic. The [migrations FAQ](/products/managed-postgres/migrations/faq)
covers common errors and recovery steps.

<h2 id="supabase">
  Migrating from Supabase
</h2>

If you're migrating from Supabase, see the [Supabase to Managed Postgres migration guide](https://github.com/iskakaushik/supa-auth-migrate/blob/main/MIGRATION.md) for a step-by-step walkthrough.