diff --git a/valkey.conf b/valkey.conf
index 320710e9b..0f43f5cc3 100644
--- a/valkey.conf
+++ b/valkey.conf
@@ -1248,8 +1248,8 @@ acllog-max-len 128
 
 ############################# LAZY FREEING ####################################
 
-# The server has two primitives to delete keys. One is called DEL and is a blocking
-# deletion of the object. It means that the server stops processing new commands
+# When keys are deleted, the served has historically freed their memory using
+# blocking operations. It means that the server stopped processing new commands
 # in order to reclaim all the memory associated with an object in a synchronous
 # way. If the key deleted is associated with a small object, the time needed
 # in order to execute the DEL command is very small and comparable to most other
@@ -1257,15 +1257,16 @@ acllog-max-len 128
 # aggregated value containing millions of elements, the server can block for
 # a long time (even seconds) in order to complete the operation.
 #
-# For the above reasons the server also offers non blocking deletion primitives
-# such as UNLINK (non blocking DEL) and the ASYNC option of FLUSHALL and
-# FLUSHDB commands, in order to reclaim memory in background. Those commands
-# are executed in constant time. Another thread will incrementally free the
-# object in the background as fast as possible.
+# For the above reasons, lazy freeing (or asynchronous freeing), has been
+# introduced. With lazy freeing, keys are deleted in constant time. Another
+# thread will incrementally free the object in the background as fast as
+# possible.
 #
-# DEL, UNLINK and ASYNC option of FLUSHALL and FLUSHDB are user-controlled.
-# It's up to the design of the application to understand when it is a good
-# idea to use one or the other. However the server sometimes has to
+# Starting from Valkey 8.0, lazy freeing is enabled by default. It is possible
+# to retain the synchronous freeing behaviour by setting the lazyfree related
+# configuration directives to 'no'.
+
+# Commands like DEL, FLUSHALL and FLUSHDB delete keys, but the server can also
 # delete keys or flush the whole database as a side effect of other operations.
 # Specifically the server deletes objects independently of a user call in the
 # following scenarios:
@@ -1285,19 +1286,18 @@ acllog-max-len 128
 #    its primary, the content of the whole database is removed in order to
 #    load the RDB file just transferred.
 #
-# In all the above cases the old default is to delete objects in a blocking way,
-# like if DEL was called. Now the new default is release memory in a non-blocking
-# way like if UNLINK was called.
+# In all the above cases, the default is to release memory in a non-blocking
+# way.
 
 lazyfree-lazy-eviction yes
 lazyfree-lazy-expire yes
 lazyfree-lazy-server-del yes
 replica-lazy-flush yes
 
-# It is also possible, for the case when to replace the user code DEL calls
-# with UNLINK calls is not easy, to modify the default behavior of the DEL
-# command to act exactly like UNLINK, using the following configuration
-# directive:
+# For keys deleted using the DEL command, lazy freeing is controlled by the
+# configuration directive 'lazyfree-lazy-user-del'. The default is 'yes'. The
+# UNLINK command is identical to the DEL command, except that UNLINK always
+# frees the memory lazily, regardless of this configuration directive:
 
 lazyfree-lazy-user-del yes