diff --git a/docs/_docs/SQL/sql-calcite.adoc b/docs/_docs/SQL/sql-calcite.adoc
index d60a732cd66bc..bc7136233bbcf 100644
--- a/docs/_docs/SQL/sql-calcite.adoc
+++ b/docs/_docs/SQL/sql-calcite.adoc
@@ -1270,10 +1270,23 @@ So, when `txAwareQueriesEnabled = true` enabled the usage:
 ====
 [discrete]
 === SELECT ... FOR UPDATE
-Currently, no locks are held by the UPDATE or SELECT statements.
-`SELECT ... FOR UPDATE` statement not supported.
-This means lost updates can occur when multiple transactions concurrently modify the same key.
+The Calcite-based query engine supports `SELECT ... FOR UPDATE` inside a `PESSIMISTIC` transaction.
+The statement acquires row-level locks for the cache entries returned by the query and returns the selected rows.
 
-For example, if you execute a query like `SET salary = salary + 50 WHERE id = 1` concurrently across multiple threads,
-note that due to the lost-update anomaly, the final value may not equal the original salary plus 50 multiplied by the number of threads.
+[source,sql]
+----
+SELECT id, salary FROM Person WHERE id = 1 FOR UPDATE;
+SELECT p.id FROM Person p JOIN Dept d ON p.deptId = d.id FOR UPDATE OF p.id;
+SELECT id FROM Person WHERE id = 1 FOR UPDATE NOWAIT;
+SELECT id FROM Person WHERE id = 1 FOR UPDATE WAIT 5;
+----
+
+Without `OF`, rows from all cache-based tables participating in the query are locked.
+With `OF`, only rows from the tables that own the listed columns are locked.
+`NOWAIT` fails immediately if a required lock cannot be acquired.
+`WAIT n` waits up to `n` seconds.
+If neither option is specified, Ignite uses the transaction timeout.
+
+`SELECT ... FOR UPDATE` is supported only for plain `SELECT` queries over cache-based tables and joins of such tables.
+It is not supported for `DISTINCT`, `GROUP BY`, `HAVING`, aggregate-only result sets, system views, or table functions.
 ====