Merge branch 'docs' into postgres-bucket-storage

Author: benitav

usage/lifecycle-maintenance/compacting-buckets.mdx

@@ -82,7 +82,6 @@ DELETE FROM lists WHERE name = 'b';
 
 After compacting, the bucket looks like this:
 
-
 ```bash
 (1, PUT, row_1, <data>)
 (2, MOVE)
@@ -95,7 +94,7 @@ After compacting, the bucket looks like this:
 (100001, REMOVE, row50000)
 ```
 
-This is inefficient, since we have over 100k operations for downloading a single actual row.
+This is inefficient, since we have over 100k operations for downloading a single row.
 
 To handle this case, we "defragment" the bucket by updating existing rows in the source database. In this case, we can run:
 
@@ -115,6 +114,10 @@ This creates a new PUT operation at the end of the bucket, which allows the comp
 
 The bucket is now back to two operations, allowing new clients to sync efficiently.
 
+<Check>
+Note: All rows in the bucket must be updated for this to be effective.
+</Check>
+
 ### Defragmenting trade-offs
 
 Defragmenting + compacting as described above can significantly reduce the number of operations in a bucket, at the cost of existing clients needing to re-sync that data. When and how to do this depends on the specific use-case and data update patterns.
@@ -137,4 +140,4 @@ In the future, we may use [incremental sync rule reprocessing](https://roadmap.p
 
 ## Technical details
 
-See the [documentation](https://github.com/powersync-ja/powersync-service/blob/main/docs/compacting-operations.md) in the `powersync-service` repo for more technical details on compacting.
+See the [documentation](https://github.com/powersync-ja/powersync-service/blob/main/docs/compacting-operations.md) in the `powersync-service` repo for more technical details on compacting.