Resolve duplicate rows with explicit SQL ​

Coordinator DB does not offer a FINAL query modifier or an OPTIMIZE FINAL maintenance operation. Model uniqueness with a declared key, and make the rule for replacing a row explicit in the write operation.

CREATE TABLE inventory(id INTEGER PRIMARY KEY, quantity Int64);
INSERT INTO inventory VALUES (1, 5);
INSERT INTO inventory VALUES (1, 8)
ON CONFLICT(id) DO UPDATE SET quantity = excluded.quantity;

This example keeps one row per identifier and replaces its quantity. It does not choose the latest event by timestamp or deduplicate arbitrary existing rows. Define that business rule separately, including how ties are handled.

Repair an existing dataset ​

First query the candidate key to find duplicates and preserve a backup before changing data. Build a replacement table with the intended key and populate it using a SELECT that expresses which rows survive. Validate counts, totals and representative identifiers before changing the application's table reference.

For changes spanning several statements, use a transaction so the intended unit can commit or roll back together. Formatted input does not accept an ON CONFLICT clause; load into a staging table when you need a later conflict-aware SQL step.

See INSERT conflict handling, table definitions and transactions.