What's changing: MSSQL (SQL Server) replication now pins each source-table binding to a specific CDC capture instance and keeps the replicated table set and captured schema fixed for the lifetime of a replication stream, instead of automatically adopting a newer capture instance or re-snapshotting on schema changes. Table wildcards (%) are no longer supported for MSSQL — tables must be listed explicitly. Adopting a schema change (new/changed columns, a newer capture instance, or an added table) now requires deploying an updated sync configuration as a new replication stream. If an active stream detects that a replicated table was dropped or renamed, replication now stops with a new error rather than automatically re-snapshotting.
High priority — existing docs are now inaccurate or incomplete
- SQL Server Specifics, in Implementing Schema Changes (
https://docs.powersync.com/maintenance-ops/implementing-schema-changes#sql-server-specifics) — currently states "PowerSync will automatically detect and use the new capture instance for the source table," and that a RENAME "is automatically detected and results in the removal of the bucket data for the old table, followed by a snapshot of the newly renamed table," with replication resuming once the snapshot completes. Both are now wrong: streams stay pinned to their original capture instance/schema regardless of newer instances appearing, and a detected drop or rename now stops replication instead of being applied automatically.
- Error Codes Reference (
https://docs.powersync.com/debugging/error-codes#psync_s16xx-mssql-replication-issues) — the PSYNC_S16xx: MSSQL replication issues section currently documents only PSYNC_S1601. The PR adds PSYNC_S1602 (initial table validation failure: table unavailable, not CDC-enabled, or no capture instance available) and PSYNC_S1603 (a replicated table was dropped or renamed while streaming), neither of which appear on this page.
For reviewer consideration — may be worth documenting
- Advanced SQL Server Configuration (
https://docs.powersync.com/configuration/source-db/sql-server-additional-configuration) and Source Database Setup (https://docs.powersync.com/configuration/source-db/setup#sql-server) don't mention that tables must now be listed explicitly (no wildcard support) or that any MSSQL schema change requires deploying a new replication stream — reviewer's call on whether that belongs on the schema-changes page, these config pages, or both.
- PR is still open (
mergeable_state: blocked, 20 commits, review in progress as of filing) — the design could still change before merge.
Source PR: powersync-ja/powersync-service#727 (open, "Product Visibility" label, as of 2026-08-05)
Note: docs.powersync.com (llms.txt/llms-full.txt) was unreachable from this run's sandboxed network (egress policy denial). Verification above was done directly against the current MDX source in this repo instead.
Filed automatically by Claude Code (claude-sonnet-5). A human must verify the scope, prepare the docs PR, and publish it only once this update has been released.
What's changing: MSSQL (SQL Server) replication now pins each source-table binding to a specific CDC capture instance and keeps the replicated table set and captured schema fixed for the lifetime of a replication stream, instead of automatically adopting a newer capture instance or re-snapshotting on schema changes. Table wildcards (
%) are no longer supported for MSSQL — tables must be listed explicitly. Adopting a schema change (new/changed columns, a newer capture instance, or an added table) now requires deploying an updated sync configuration as a new replication stream. If an active stream detects that a replicated table was dropped or renamed, replication now stops with a new error rather than automatically re-snapshotting.High priority — existing docs are now inaccurate or incomplete
https://docs.powersync.com/maintenance-ops/implementing-schema-changes#sql-server-specifics) — currently states "PowerSync will automatically detect and use the new capture instance for the source table," and that a RENAME "is automatically detected and results in the removal of the bucket data for the old table, followed by a snapshot of the newly renamed table," with replication resuming once the snapshot completes. Both are now wrong: streams stay pinned to their original capture instance/schema regardless of newer instances appearing, and a detected drop or rename now stops replication instead of being applied automatically.https://docs.powersync.com/debugging/error-codes#psync_s16xx-mssql-replication-issues) — thePSYNC_S16xx: MSSQL replication issuessection currently documents onlyPSYNC_S1601. The PR addsPSYNC_S1602(initial table validation failure: table unavailable, not CDC-enabled, or no capture instance available) andPSYNC_S1603(a replicated table was dropped or renamed while streaming), neither of which appear on this page.For reviewer consideration — may be worth documenting
https://docs.powersync.com/configuration/source-db/sql-server-additional-configuration) and Source Database Setup (https://docs.powersync.com/configuration/source-db/setup#sql-server) don't mention that tables must now be listed explicitly (no wildcard support) or that any MSSQL schema change requires deploying a new replication stream — reviewer's call on whether that belongs on the schema-changes page, these config pages, or both.mergeable_state: blocked, 20 commits, review in progress as of filing) — the design could still change before merge.Source PR: powersync-ja/powersync-service#727 (open, "Product Visibility" label, as of 2026-08-05)
Note:
docs.powersync.com(llms.txt/llms-full.txt) was unreachable from this run's sandboxed network (egress policy denial). Verification above was done directly against the current MDX source in this repo instead.Filed automatically by Claude Code (
claude-sonnet-5). A human must verify the scope, prepare the docs PR, and publish it only once this update has been released.