diff --git a/installation/database-setup.mdx b/installation/database-setup.mdx
index 64bf7300..3afcc648 100644
--- a/installation/database-setup.mdx
+++ b/installation/database-setup.mdx
@@ -456,7 +456,6 @@ For more information about CDC, see:
 
 - Schema change handling is not supported yet.
 - Spatial data types are returned as JSON objects as supplied by the Tedious `node-mssql` client. See the notes [here](https://github.com/tediousjs/node-mssql?tab=readme-ov-file#geography-and-geometry).
-- Due to limitations in the `node-mssql` client, temporal data types are returned with a maximum precision level of milliseconds.
 - There is an inherent latency in replicating data from SQL Server to PowerSync. See [Latency](#latency) for more details.
 
 ### Database Setup Requirements
diff --git a/usage/sync-rules/compatibility.mdx b/usage/sync-rules/compatibility.mdx
index 6064486c..ba8550b6 100644
--- a/usage/sync-rules/compatibility.mdx
+++ b/usage/sync-rules/compatibility.mdx
@@ -64,6 +64,35 @@ For instance, the value `2025-09-22T14:29:30` would be encoded as follows:
 
 Note that MySQL has never been affected by this issue, and thus behaves the same regardless of the option used.
 
+#### Configurable sub-second datetime precision
+
+When the `timestamps_iso8601` option is enabled, PowerSync will synchronize date and time values with a higher
+precision depending on the source database.
+You can use the `timestamp_max_precision` option to configure the actual precision to use.
+For instance, a Postgres timestamp value would sync as `2025-09-22T14:29:30.000000` by default.
+If you don't want that level of precision, you can use the following options to make it sync as `2025-09-22T14:29:30.000`:
+
+```yaml sync_rules.yaml
+config:
+  edition: 2
+  timestamp_max_precision: milliseconds
+```
+
+Valid options for `timestamp_max_precision` are `seconds`, `milliseconds`, `microseconds` and `nanoseconds`. When an explicit
+value is given, all synced time values will use that precision.
+If a source value has a higher precision, it will be truncated (it is not rounded).
+If a source value has a lower precision, it will be padded (so setting the option to `microseconds` with a MongoDB source database
+will sync values as `2025-09-22T14:29:30.123000`, with the last three sub-second digits always being set to zero).
+
+If no option is given, the default precision depends on the source database:
+
+| Source database | Default precision | Max precision | Notes                                                                                                   |
+|-----------------|-------------------|---------------|---------------------------------------------------------------------------------------------------------|
+| MongoDB         | Milliseconds      | Milliseconds  |                                                                                                         |
+| Postgres      | Microseconds      | Microseconds  |                                                                                                         |
+| MySQL           | Milliseconds      | Microseconds  | Defaults to milliseconds, but can be expanded with the option.                                          |
+| SQL Server      | Nanoseconds       | Nanoseconds   | SQL Server supports 7 digits of accuracy, the sync service pads values to always use 9 for nanoseconds.  |
+
 ### `versioned_bucket_ids`
 
 Sync Rules define buckets, which rows to sync are then assigned to. When you run a full defragmentation or