From Upstash Redis

Upstash Redis databases move to Databasezy Valkey, which speaks the same protocol. Keys are copied with their TTLs.

Upstash Redis migration at a glance, from the migration source catalogue

Status	Available
Target engines	Valkey
How we read it	Connection string
Continuous sync	No, copy only
Provider preset	upstash

Before you start

• A Databasezy Valkey instance, or use --create.
• The database’s Redis URL with its password.
• If you use the Upstash REST client, a plan to switch to a TCP client.

Find the connection string

In the Upstash console, open the database and copy the Redis connection URL from its details. Use the TCP URL, not the REST URL: the REST API has no DUMP/RESTORE.

Upstash Redis notes

• Keys are copied with DUMP/RESTORE over TLS, keeping TTLs; Lua scripts and streams consumer groups are listed separately.

Upstash accepts TLS only, so the preset rewrites redis:// to rediss:// (upstash.tls_rewritten). Keys are read with SCAN and DUMP/PTTL and written with RESTORE ... REPLACE. Upstash rate-limits commands on some plans, so large keyspaces copy slowly.

Migrate

Portal

1. Open the target Valkey instance (create one first if you need to) and choose the Migrate in tab.
2. Under Source, pick Connection string and paste the URL. The host is recognised as Upstash Redis; you can also pick it from the provider list.
3. Run Preflight and work through the checklist. Blocking items must be fixed before the copy starts.
4. Start the copy and follow Copy and Verify. Mismatches are listed per table or collection.
5. Point your application at the new instance. The Report step keeps the timings and verification results.

CLI

shell

# Dry run: print the preflight checklist and the plan, change nothing
zb migrate --from "rediss://default:[email protected]:6379" --to inst_abc --dry-run

# Start it (or use --create --size s1 instead of --to to create the target)
zb migrate --from "rediss://default:[email protected]:6379" --to inst_abc

zb migrate status mig_123

API

shell

curl -sS https://api.databasezy.com/v1/orgs/$ZB_ORG/instances/inst_abc/migrations \
  -H "Authorization: Bearer $ZB_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
  "source": {
    "kind": "connection_string",
    "url": "rediss://default:[email protected]:6379",
    "provider": "upstash"
  },
  "mode": "copy"
}'

# Follow progress, preflight report and verification
curl -sS https://api.databasezy.com/v1/orgs/$ZB_ORG/instances/inst_abc/migrations/mig_123 -H "Authorization: Bearer $ZB_API_KEY"

Upstash’s HTTP REST API (@upstash/redis) has no equivalent on Valkey. Switch to a TCP client such as ioredis, valkey-go or redis-py, as on the Valkey engine page. On edge runtimes without TCP, keep cache access behind a server function.

Verify

Verification compares the key count on both sides once the copy finishes. Spot-check a few keys you know, including their TTLs (PTTL <key>), and run your application against the new instance before you switch traffic.

Cutover

This source is copy only. Writes that reach the source after the copy starts are not carried over, so for a database that changes, stop writes before you start the copy (maintenance mode, or scale writers to zero), run the migration, check verification, then point the application at the Databasezy connection string.

Roll back

A migration never deletes anything on the source. Until you decommission it, rolling back means pointing the application back at the source. Writes made on Databasezy after you switched are not on the source; if you need them, copy them back before switching. Cancel a running migration with zb migrate cancel <mig_id>; partially restored data stays on the target, so restart with --drop-target or delete the instance.

Troubleshooting

The copy is slow

Upstash plans with command limits throttle SCAN and DUMP. Run the copy at a quiet time or raise the plan limit for the duration.

Preflight cannot connect to the source

Check that the source accepts connections from the egress addresses preflight prints, that the host is the public one and that the password has not been rotated. zb migrate --dry-run shows the exact URL that will be used after any rewrites.

Preflight lists blocking items

Each item has a machine code and a fix. Nothing is written to the target until every blocking item is resolved; warnings do not block.

Fewer keys on the target than on the source

Keys that expired during the copy are not restored, and keys written after the copy started may be missed. Compare again after a short write freeze.

For anything else, zb migrate status <mig_id> shows the failing step and its message. How migrations work describes every step.