How to Migrate from On-Premise to ParadeDB in PostgreSQL

How do I migrate my on-premise PostgreSQL database to ParadeDB?

Dump your on-premise PostgreSQL database, restore it into ParadeDB, and enable the ParadeDB extension to unlock cloud-native search and analytics.

Welcome to the Galaxy, Guardian!
You'll be receiving a confirmation email

Follow us on twitter :)

Oops! Something went wrong while submitting the form.

Description

Example H2

Example H3

Why migrate to ParadeDB?

ParadeDB adds vector search, hybrid search, and fast analytics without changing your application code. Moving your existing data lets you test these features immediately.

What prerequisites must be met?

Ensure your on-prem PostgreSQL version matches (or is lower than) ParadeDB’s target version. Install pg_dump/pg_restore that match your source server.

How do I dump my on-prem database?

Use pg_dump with custom format so you can restore in parallel:

pg_dump -Fc \ --jobs=4 \ --no-owner \ --dbname=postgresql://user:pass@onprem.host:5432/store \ --file=store.dump

How is ParadeDB restored?

Create an empty database in ParadeDB Cloud, then stream the dump:

pg_restore -j 4 \ --create \ --dbname=postgresql://user:pass@parade.cloud:5432/postgres \ store.dump

When do I run CREATE EXTENSION?

After the schema is in place, enable ParadeDB:

\c store CREATE EXTENSION IF NOT EXISTS paradedb;

How do I re-index text or vector columns?

Rebuild GIN or HNSW indexes so ParadeDB can optimize queries:

CREATE INDEX idx_products_search ON products USING paradedb_hnsw (to_vector(name));

What about large order tables?

Restore in parallel, disable triggers, and then ANALYZE to refresh statistics:

ALTER TABLE orders DISABLE TRIGGER ALL; -- bulk load data ALTER TABLE orders ENABLE TRIGGER ALL; ANALYZE orders;

How do I cut over with minimal downtime?

1) Take initial dump, 2) restore to ParadeDB, 3) enable logical replication from on-prem to ParadeDB for catch-up, 4) switch traffic once lag is zero.

Best practices checklist

- Match server versions
- Use custom dump format
- Restore in parallel
- Rebuild indexes
- ANALYZE after import
- Test application queries

Common mistakes

See below for frequent pitfalls and fixes.

Why How to Migrate from On-Premise to ParadeDB in PostgreSQL is important

How to Migrate from On-Premise to ParadeDB in PostgreSQL Example Usage


-- Verify customers imported
SELECT id, name, email
FROM customers
ORDER BY created_at DESC
LIMIT 10;

-- Test ParadeDB vector search on products
SELECT id, name, price
FROM products
WHERE paradedb_match(name, 'wireless earbuds')
ORDER BY paradedb_score DESC
LIMIT 5;

How to Migrate from On-Premise to ParadeDB in PostgreSQL Syntax


pg_dump [connection-options] -Fc [flags] -f &lt;file&gt;
pg_restore [connection-options] [flags] &lt;file&gt;

Example (ecommerce):
pg_dump -Fc --no-owner \
  --dbname=postgresql://admin:pw@onprem:5432/store \
  --table=customers --table=orders --table=products --table=orderitems \
  --file=store.dump

pg_restore --create -j 4 \
  --dbname=postgresql://admin:pw@parade.cloud:5432/postgres \
  store.dump

Common Mistakes

Using mismatched pg_dump/pg_restore versions: Tools newer than the source server can fail silently. Always install client binaries that match the source server or use the oldest version across both environments.
Forgetting to recreate extensions: pg_dump excludes binaries like PostGIS or pg_trgm by default. Run CREATE EXTENSION in ParadeDB after restore to avoid "function does not exist" errors.