The index uses key as identity. Changing that identity is not an in-place value update under the old key. In Debezium's PostgreSQL connector documentation, a primary-key change is represented as a delete and tombstone for the old key followed by a create for the new key. If a consumer handles only the new upsert, drops tombstones, or loses the old-key event during routing, the old index entry remains. This is a concrete connector behavior, so inspect the actual connector and topic configuration before assuming every CDC system emits this exact sequence.

I would trace source transaction ID, old and new keys, event keys, partition placement, offsets and index mutation logs. Do not assume the old and new key events share a partition or that arrival order across partitions is globally guaranteed. The consumer needs to delete the old indexed identity and create the new one, with retries and version checks so a late event cannot resurrect the old identity. If the search document ID is derived from a mutable business key, consider a stable source row identity or explicit alias map. A stable ID simplifies moves but does not remove the need to update the searchable business identifier and permissions.

Test key changes with one row, then with concurrent updates and a restart between delete and create. A partially applied change can temporarily make the row absent or duplicated. Decide whether the product tolerates that window or needs a staged atomic index swap or read-time reconciliation. An assistant answer should not count duplicate index hits as two entities when the source of truth has one. If one of the hits is from an older revision, expose that mismatch rather than silently merging contradictory facts.

Would an eventual consistency promise excuse this? Only for a bounded and observable interval. Record per-source revision or cursor watermarks and alert when old identities persist past the freshness target. A connector uses file paths as document IDs. What breaks on a move? covers a connector incorrectly treating a moved file path as a new document ID. A deleted customer document returned after an index rebuild. Which deletion did replay miss? covers an old snapshot missing a deletion tombstone during rebuild. Here the source intentionally changes its primary key, and the CDC event sequence must remove the old indexed identity in normal operation.