The `INTERLEAVE IN PARENT` clause is missing `ON DELETE CASCADE`. This prevents deleting a `collections` row if it has associated compaction cursors. If the intention is to allow hard deletes of collections (e.g., via garbage collection), you must manually delete all children first without this clause.

This same pattern applies to `migrations/0007-create_segments.spanner.sql` (segments in cursors) and `migrations/0009-create_collection_metadata.spanner.sql` (metadata in collections).

Consider adding `ON DELETE CASCADE` to all interleaved tables to simplify the deletion lifecycle.

File: rust/spanner-migrations/migrations/0006-create_collection_compaction_cursors.spanner.sql
Line: 20

Interleaving `collection_segments` in `collection_compaction_cursors` creates a significant risk of lock contention.

Since `collection_compaction_cursors` tracks mutable state (like `last_compacted_offset`), its rows will likely be updated frequently by compaction jobs. Inserting rows into `collection_segments` requires a lock on the parent row to verify existence. This means ingestion (adding segments) and compaction (updating cursor) will contend for locks on the same cursor row, potentially serializing operations per region.

**Recommendation:** Interleave `collection_segments` directly in `collections`.

With `PRIMARY KEY (collection_id, region, id)`, the segments will still be physically colocated by region (due to lexicographical key ordering), achieving the same query efficiency without coupling ingestion to compaction state stability.

File: rust/spanner-migrations/migrations/0007-create_segments.spanner.sql
Line: 16

Consider defining Foreign Key constraints for `database_id` and `tenant_id` to enforce referential integrity at the database level. Without them, orphaned records could exist if parent entities are deleted (unless strict soft-delete logic is guaranteed at the application layer).

File: rust/spanner-migrations/migrations/0004-create_collections.spanner.sql
Line: 13

Storing `database_name` here creates a denormalized dependency. If a database is renamed in the source-of-truth `databases` table, this column will become stale unless explicitly synchronized. 

Unless this is a specific read-optimization trade-off, consider removing this column and joining with the `databases` table on `database_id` when the name is needed.

File: rust/spanner-migrations/migrations/0004-create_collections.spanner.sql
Line: 8

Similar to `create_tenant`, this logic fails if a database with the same name was previously soft-deleted.

The uniqueness check filters out `is_deleted = TRUE` rows, but the `INSERT` will violate the unique index on `(tenant_id, name)` (and the PK on `id` if reused) because the index includes soft-deleted rows.

Handle the conflict by checking for existing soft-deleted rows and deciding whether to revive them or return a specific error.

File: rust/rust-sysdb/src/spanner.rs
Line: 207

This creates a potential bug where creating a tenant that was previously soft-deleted will fail with a database constraint violation (PK violation) instead of handling it gracefully.

The check `is_deleted = FALSE` ignores soft-deleted rows, but the subsequent `INSERT` will collide with the existing soft-deleted row's primary key `id`.

Consider checking for the row existence regardless of `is_deleted` status, and then either reviving the tenant (UPDATE `is_deleted` = false) or returning a specific error.

File: rust/rust-sysdb/src/spanner.rs
Line: 92

The column name `last_compaction_time_secs` implies an integer value representing seconds (e.g., Unix epoch), but the type is `TIMESTAMP` with `allow_commit_timestamp=true`. This naming convention is misleading as `TIMESTAMP` in Spanner is a specific data type, not just a count of seconds.

Consider renaming to `last_compaction_time` or `last_compaction_at` to accurately reflect the data type and avoid confusion.

File: rust/spanner-migrations/migrations/0005-create_collection_compaction_cursors.spanner.sql
Line: 14

Using `todo!()` will cause the server to panic if this endpoint is triggered. For unimplemented gRPC methods, it's safer to return a `Status::unimplemented` error code. This ensures the service remains stable even if the endpoint is called accidentally.

[FileRule: rust/language_specific.instructions.rust]

File: rust/rust-sysdb/src/server.rs
Line: 489