diff --git a/docs/1.2/sql/indexes.md b/docs/1.2/sql/indexes.md
index 2e3da684ce8..7e2829e5e52 100644
--- a/docs/1.2/sql/indexes.md
+++ b/docs/1.2/sql/indexes.md
@@ -108,4 +108,25 @@ Violates foreign key constraint because key "id: 1" is still referenced by a for
 ```
 
 The reason for this is because DuckDB does not yet support “looking ahead”.
-During the `INSERT`, it is unaware it will reinsert the foreign key value as part of the `UPDATE` rewrite.
\ No newline at end of file
+During the `INSERT`, it is unaware it will reinsert the foreign key value as part of the `UPDATE` rewrite.
+
+### Constraint Checking After Delete With Concurrent Transactions
+
+When a delete is committed on a table with an ART index, data can only be removed from the index when no further transactions exist that refer to the deleted entry. This means if you perform a delete transaction, a subsequent transaction which inserts a record with the same key as the deleted record can fail with a constraint error if there is a concurrent transaction referencing the deleted record. Pseudocode to demonstrate:
+
+```
+// Assume "someTable" is a table with an ART index preventing duplicates
+tx1 = duckdbTxStart()
+someRecord = duckdb(tx1, "select * from someTable using sample 1 rows")
+
+tx2 = duckdbTxStart()
+duckdbDelete(tx2, someRecord)
+duckdbTxCommit(tx2)
+
+// At this point someRecord is deleted, but the ART index is not updated, so the following would fail with a constraint error:
+// tx3 = duckdbTxStart()
+// duckdbInsert(tx3, someRecord)
+// duckdbTxCommit(tx3)
+
+duckdbTxCommit(tx1) // Following this, the above insert would succeed because the ART index was allowed to update
+```