v0.99.30

New: index-build overlap now extends to MySQL targets, and the PG-source sync start cold-start gets within-table chunking — plus a SPATIAL/FULLTEXT-to-MySQL migration fix. sluice migrate to a MySQL target (MySQL→MySQL and PG→MySQL) now builds each table's secondary indexes as that table's copy lands, concurrently with the still-copying tables — the same structural collapse of the separate post-copy index phase that Postgres targets got in v0.99.29 (ADR-0077), now on MySQL (ADR-0080). Separately, the fast PG-source sync start cold-start (introduced in v0.99.29) now chunks a large single table into parallel PK-ranges instead of single-streaming it (ADR-0079 v1.1). And a pre-existing bug that made SPATIAL/FULLTEXT index creation fail with MySQL Error 1089 is fixed. Drop-in from v0.99.29 — both speedups are automatic / capability-detected; no config change required.

Features

• Index-build overlap extended to MySQL targets (ADR-0080). sluice migrate with a MySQL target (MySQL→MySQL and PG→MySQL) now builds each table's secondary indexes as soon as that table's copy lands, concurrently with the still-copying tables — collapsing the separate post-copy whole-schema index phase, the same structural win Postgres targets got in v0.99.29 (ADR-0077). Mechanism: the MySQL SchemaWriter now implements the engine-neutral ir.IncrementalIndexBuilder + ir.TableIndexedNotifier surfaces, draining the orchestrator's completed-tables channel into a bounded worker pool that each builds one table's indexes (ALTER TABLE … ADD INDEX, detect-then-skip) on its own connection. Two MySQL-specific deviations from the PG path: MySQL has no connection-slot prober, so the index pool sizes itself from a fixed worker count (default 4) rather than a measured budget; and PlanetScale/Vitess targets decline the overlap and defer to their own online-DDL / Safe-Migrations queue (the channel is drained into a no-op that still fires the per-table callback so resume accounting stays correct, then the post-copy whole-schema CreateIndexes runs as before). Idempotent on resume via the existing detect-then-skip index-exists probe. No throughput number is claimed yet — it needs an at-scale MySQL measurement (Postgres's overlap was disk-bound-neutral at 110 GB; the win grows on faster storage). Pinned by unit tests on the worker-sizing + flavor-decline policy and a MySQL integration test asserting the overlap actually happened.

• Within-table chunking on the PG-source sync start fast cold-start (ADR-0079 v1.1). v0.99.29 gave the fast sync start cold-start cross-table parallelism + index-overlap + raw passthrough; v0.99.30 adds within-table PK-range chunking, so a large single table on the sync path is copied in parallel chunks too instead of single-streamed. The chunker engages when the source table has planner stats (pg_class.reltuples); a never-ANALYZEd table stays single-stream — slower, never lossy. PG-source only. Mechanism: a new optional ir.RowCountEstimator surface (sibling to RowCounter) carries the chunk-decision-only row estimate; the PG implementation reads reltuples off a separate connection so it never races the live snapshot stream pinned to the exported snapshot. This deliberately keeps the throughput/ETA probe untouched and out of the pinned reader, so the estimate path can never conflict with the in-flight copy. Only the chunk-decision estimate changes — a wrong estimate degrades to single-stream, never corrupts the copy. Pinned by the within-table-chunking-engaged integration test on the sync cold-start.

Fixed

• MySQL SPATIAL / FULLTEXT index creation no longer fails with Error 1089. sluice emitted a per-column prefix length (e.g. pt(32)) on SPATIAL and FULLTEXT indexes, which MySQL rejects with Error 1089 ("Incorrect prefix key; the used key part isn't a string…") — so the index was never created and the migration errored. The source reader can legitimately surface a SUB_PART (length) on a geometry or full-text index column; the prefix is now dropped at emit time for those two index kinds (every other index kind keeps the source's prefix length). This affected any migration carrying a SPATIAL or FULLTEXT secondary index to a MySQL target, on both the serial post-copy CreateIndexes path and the new overlapped path. Pre-existing bug, first surfaced by the ADR-0080 MySQL index-overlap work. This is a loud failure (the migration errors with Error 1089 — the index is simply not created; it is not silent data loss), so no data re-verification is needed. Pinned by unit tests asserting prefix suppression on both spatial and fulltext.

Compatibility

• No breaking changes. Drop-in from v0.99.29. Both speedups are automatic / capability-detected — no config change is required.
• MySQL index-overlap is automatic on any MySQL-target migrate (MySQL→MySQL and PG→MySQL). PlanetScale/Vitess targets are unaffected — they decline the overlap and defer to platform online-DDL, falling back to the post-copy whole-schema index build exactly as before.
• The sync within-table chunking is automatic on PG-source sync start cold-start when source table stats exist; a never-ANALYZEd table stays single-stream. PG-source only — MySQL/VStream/PlanetScale sync cold-starts are unchanged.
• Unaffected: PG-target index-overlap (already shipped v0.99.29), migrate resume, sync warm-resume, multi-database / multi-schema cold-start, and all cross-engine copies stay on their existing paths. The SPATIAL/FULLTEXT emit fix changes only the DDL emitted for those two index kinds; all other index DDL is byte-identical.

Who needs this — action required

• Anyone migrating to a MySQL target at scale — the index-overlap collapses the separate post-copy index phase into the copy. No action required: it engages automatically; PlanetScale/Vitess targets are untouched.
• Anyone doing PG→PG or PG-source continuous sync start of large tables — the within-table chunking makes the fast cold-start parallelise a single large table too. No action required: it engages automatically when source stats exist.
• Anyone migrating a SPATIAL or FULLTEXT indexed table to a MySQL target — this path previously failed loudly with Error 1089 and the index was not created. Upgrade to v0.99.30 for that path. Because the failure was loud (the migration errored, not a silent corruption), no data re-verification is required; operators who saw Error 1089 on a spatial/fulltext index should re-run on v0.99.30. Affected releases: every prior published version that migrated a SPATIAL/FULLTEXT secondary index to MySQL carried this — it is a pre-existing emit bug, not a recent regression.
• No re-verification of prior migrations is needed. This release contains no silent-loss fix — the two features are new (no prior release affected), and the one bug fix is a loud Error 1089 failure, not silent corruption.

---

Install: brew install sluicesync/tap/sluice · go install sluicesync.dev/sluice/cmd/sluice@v0.99.30 · Container: ghcr.io/sluicesync/sluice:0.99.30
Full changelog: https://github.com/sluicesync/sluice/blob/main/CHANGELOG.md