From Algolia
Tested with: Not yet available: planned for rollout phase 3
Algolia indexes will move to the Meilisearch engine. Both the Meilisearch engine and this source are coming soon; this page describes the planned flow.
| Status | Coming soon · phase 3 |
|---|---|
| Target engines | Meilisearch |
| How we read it | Connection string |
| Continuous sync | No, copy only |
| Provider preset | None yet (generic) |
Before you start
Section titled “Before you start”- A Databasezy Meilisearch instance (coming soon).
- Your Algolia application ID and an API key that can browse the indexes you migrate, and nothing else.
Find the connection string
Section titled “Find the connection string”In the Algolia dashboard, find the application ID and create an API key limited to the browse permission on the
indexes you want to copy. Do not use the admin key.
Algolia notes
Section titled “Algolia notes”- Records are read with a read-only API key; ranking rules and synonyms are mapped to Meilisearch settings where an equivalent exists.
Index settings without a Meilisearch equivalent are listed in the preflight report rather than silently dropped.
Migrate
Section titled “Migrate”When this source ships, you will start it from the Meilisearch instance’s Migrate in tab or with zb migrate,
giving the application ID, the browse key and the index names. The exact input format is published with the preset.
Until then, export records with Algolia’s browse API and push them with Meilisearch’s documents API.
Verify
Section titled “Verify”Verification compares what the engine exposes: row counts per table for SQL engines, document counts per collection
for document engines, key counts for key-value engines. Mismatches are listed in zb migrate status <mig_id> and
the Verify step. Run your application’s tests against the new instance before you switch traffic.
Cutover
Section titled “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
Section titled “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
Section titled “Troubleshooting”Preflight cannot connect to the source
Section titled “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
Section titled “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.
For anything else, zb migrate status <mig_id> shows the failing step and its message. How migrations work describes every step.