Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 0 additions & 1 deletion installation/database-setup.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -448,7 +448,7 @@
| Database | Edition | Version | Min Service Tier |
| ---------------- | ------------------------------------------- | ------- | ------------------------------------------------------------------------------------- |
| SQL Server 2022+ | Standard, Enterprise, Developer, Evaluation | 16.0+ | N/A |
| Azure SQL\* | Database, Managed instance | N/A | Any service tier on vCore purchasing model. S3 tier and up on DTU purchasing model. See: [Azure SQL Database compute requirements](https://learn.microsoft.com/en-us/azure/azure-sql/database/change-data-capture-overview?view=azuresql#azure-sql-database-compute-requirements) |

Check warning on line 451 in installation/database-setup.mdx

View check run for this annotation

Mintlify / Mintlify Validation (powersync) - vale-spellcheck

installation/database-setup.mdx#L451

Did you really mean 'vCore'?

\* Azure SQL Database is always running on the latest version of the SQL Server DB Engine

Expand All @@ -456,7 +456,6 @@

- 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
Expand All @@ -482,7 +481,7 @@

- Read/Write permissions on the `_powersync_checkpoints` table
- Read permissions on the replicated tables
- `cdc_reader` role (grants access to CDC changetables and functions)

Check warning on line 484 in installation/database-setup.mdx

View check run for this annotation

Mintlify / Mintlify Validation (powersync) - vale-spellcheck

installation/database-setup.mdx#L484

Did you really mean 'changetables'?
- `SELECT` permission on the CDC schema. (grants access to CDC metadata tables)
- `VIEW DATABASE PERFORMANCE STATE` (SQL Server and Azure SQL)
- `VIEW SERVER PERFORMANCE STATE` (SQL Server only)
Expand Down Expand Up @@ -569,7 +568,7 @@
END
```

Grant read/write access to the table for the powersync_user:

Check warning on line 571 in installation/database-setup.mdx

View check run for this annotation

Mintlify / Mintlify Validation (powersync) - vale-spellcheck

installation/database-setup.mdx#L571

Did you really mean 'powersync_user'?

```sql
GRANT SELECT, INSERT, UPDATE ON dbo._powersync_checkpoints TO [powersync_user];
Expand Down Expand Up @@ -609,9 +608,9 @@
Recommended Capture Job settings:
| Parameter | Recommended Value |
|-------------------------|-------------------|
| maxtrans | 5000 |

Check warning on line 611 in installation/database-setup.mdx

View check run for this annotation

Mintlify / Mintlify Validation (powersync) - vale-spellcheck

installation/database-setup.mdx#L611

Did you really mean 'maxtrans'?
| maxscans | 10 |

Check warning on line 612 in installation/database-setup.mdx

View check run for this annotation

Mintlify / Mintlify Validation (powersync) - vale-spellcheck

installation/database-setup.mdx#L612

Did you really mean 'maxscans'?
| pollinginterval| 1 second |

Check warning on line 613 in installation/database-setup.mdx

View check run for this annotation

Mintlify / Mintlify Validation (powersync) - vale-spellcheck

installation/database-setup.mdx#L613

Did you really mean 'pollinginterval'?

<Note>
For Azure SQL Database, the CDC capture and cleanup jobs are managed automatically. Manual configuration is greatly limited.
Expand Down
29 changes: 29 additions & 0 deletions usage/sync-rules/compatibility.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -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
Copy link
Collaborator

@benitav benitav Dec 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this option still needs to be added to the This table lists all fixes currently supported: section

Copy link
Contributor Author

@simolus3 simolus3 Dec 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Technically it's not really a "fix" right? The fix is timestamps_iso8601, this just adds more options in case users realize they want the fixed format but not the fixed precision :D


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
Expand Down