diff --git a/pages/fundamentals/storage-memory-usage.mdx b/pages/fundamentals/storage-memory-usage.mdx
index 38c9795c2..de77773e3 100644
--- a/pages/fundamentals/storage-memory-usage.mdx
+++ b/pages/fundamentals/storage-memory-usage.mdx
@@ -186,6 +186,9 @@ If the returned graph element has been deleted by a parallel transaction, the
 built-in behavior is as follows:
 * [procedures](/advanced-algorithms/run-algorithms#run-procedures-from-mage-library): skip all records that contain any deleted value
 * [functions](/querying/functions): return a null value
+
+Please note that deleting same part of the graph from parallel transaction will lead to undefined behavior.
+
 Users developing [custom query procedures and functions](/custom-query-modules) intended to work in the
 analytical storage mode should use API methods to check if Memgraph is running
 in a transactional (ACID-compliant) storage mode. If not, the query module APIs
diff --git a/pages/querying/schema.mdx b/pages/querying/schema.mdx
index 0f73438b6..aa3bc5500 100644
--- a/pages/querying/schema.mdx
+++ b/pages/querying/schema.mdx
@@ -11,6 +11,13 @@ Schema queries are designed to retrieve information about the structure of the d
 
 ## Run-time schema tracking
 
+<Callout type="info">
+
+Please use a snapshot to migrate a pre v2.21 datasets with properties on edges.
+When schema is tracked, recovering using WAL files generated pre v2.21 will incur a performance penalty as crucial data is missing, which leads to long scan times.
+
+</Callout>
+
 To use run-time schema tracking, start Memgraph with the `--schema-info-enabled` [configuration flag](/configuration/configuration-settings#other) set to `True`. Once enabled, every change to the data layout will be tracked, and a derived schema will be automatically updated. Note that enabling this feature may result in a slight performance decrease; for more details, refer to [Performance Tips](#performance-tips).
 
 ### What Schema Information is Tracked?
@@ -248,7 +255,7 @@ Enabling `--schema-info-enabled` incurs a performance cost because additional wo
 #### Performance Tips
 * __Label Changes on Nodes with Edges__: Changing labels on a node with existing edges can invalidate large parts of the schema. To avoid blocking queries during schema updates, define node labels before adding edges. Queries such as `CREATE (:A)-[:EDGE]->(:B)` are also fine.
 * __Edge Property Type Changes__: Modifying the type of an edge's property may require scanning large portions of the graph. To avoid this, define edges and their properties in the same transaction and keep property types stable.
-* __Recovery Using WALs__: Recovering edges with properties via Write-Ahead Log (WAL) files can cause a significant performance hit. To mitigate this, use snapshots instead. Starting from v2.21, this issue will be alleviated, though not completely resolved.
+* __Recovery Using WALs__: Recovering edges with properties via Write-Ahead Log (WAL) files can cause a significant performance hit. To mitigate this, use snapshots instead. Starting from v2.21, this issue has been alleviated, when using WAL files created by v2.21+.
 
 ## Schema metadata