diff --git a/README.md b/README.md index 8fa4fc2a..449fdbe4 100644 --- a/README.md +++ b/README.md @@ -64,6 +64,7 @@ We use the following icons for supported backend databases and SDKs: - Postgres: `icon="elephant"` - MongoDB: `icon="leaf"` - MySQL: `icon="dolphin"` +- SQL Server: `icon="server"` - Flutter: `icon="flutter"` - React Native: `icon="react"` - Web: `icon="js"` diff --git a/architecture/architecture-overview.mdx b/architecture/architecture-overview.mdx index 5259e1a4..f4b7b804 100644 --- a/architecture/architecture-overview.mdx +++ b/architecture/architecture-overview.mdx @@ -10,12 +10,8 @@ description: "The core components of PowerSync are the service and client SDKs" The [PowerSync Service](/architecture/powersync-service) and client SDK operate in unison to keep client-side SQLite databases in sync with a backend database. Learn about their architecture: - - - - - - + + ### Protocol @@ -23,12 +19,8 @@ The [PowerSync Service](/architecture/powersync-service) and client SDK operate Learn about the sync protocol used between PowerSync clients and a [PowerSync Service](/architecture/powersync-service): - - - - - - + + ### Self-Hosted Architecture @@ -36,7 +28,5 @@ Learn about the sync protocol used between PowerSync clients and a [PowerSync Se For more details on typical architecture of a production self-hosted deployment, see here: - - - + \ No newline at end of file diff --git a/architecture/powersync-protocol.mdx b/architecture/powersync-protocol.mdx index 89b466a9..9a4fe36e 100644 --- a/architecture/powersync-protocol.mdx +++ b/architecture/powersync-protocol.mdx @@ -67,4 +67,4 @@ Write checkpoints are used to ensure clients have synced their own changes back Creating a write checkpoint is a separate operation, which is performed by the client after all data has been uploaded. It is important that this happens after the data has been written to the backend source database. -The server then keeps track of the current CDC stream position on the database (LSN in Postgres, resume token in MongoDB, or GTID + Binlog Position in MySQL), and notifies the client when the data has been replicated, as part of checkpoint data in the normal data stream. +The server then keeps track of the current CDC stream position on the database (LSN in Postgres & SQL Server, resume token in MongoDB and GTID + Binlog Position in MySQL), and notifies the client when the data has been replicated, as part of checkpoint data in the normal data stream. diff --git a/images/architecture/powersync-docs-diagram-architecture-overview.png b/images/architecture/powersync-docs-diagram-architecture-overview.png old mode 100755 new mode 100644 index 010dd911..0b71ce3f Binary files a/images/architecture/powersync-docs-diagram-architecture-overview.png and b/images/architecture/powersync-docs-diagram-architecture-overview.png differ diff --git a/installation/app-backend-setup.mdx b/installation/app-backend-setup.mdx index b59b87eb..d314e1c9 100644 --- a/installation/app-backend-setup.mdx +++ b/installation/app-backend-setup.mdx @@ -7,7 +7,7 @@ PowerSync generally assumes that you have some kind of "backend application" as When you integrate PowerSync into your app project, PowerSync relies on that "backend application" for a few purposes: -1. **Allowing client-side write operations to be uploaded** and [applied](/installation/app-backend-setup/writing-client-changes) to the backend database (Postgres, MongoDB or MySQL). When you write to the client-side SQLite database provided by PowerSync, those writes are also placed into an upload queue. The PowerSync Client SDK manages uploading of those writes to your backend using the `uploadData()` function that you defined in the [Client-Side Setup](/installation/client-side-setup/integrating-with-your-backend) part of the implementation. That `uploadData()` function should call your backend application API to apply the writes to your backend database. The reason why we designed PowerSync this way is to give you full control over things like data validation and authorization of writes, while PowerSync itself requires minimal permissions. +1. **Allowing client-side write operations to be uploaded** and [applied](/installation/app-backend-setup/writing-client-changes) to the backend database (Postgres, MongoDB, MySQL, or SQL Server). When you write to the client-side SQLite database provided by PowerSync, those writes are also placed into an upload queue. The PowerSync Client SDK manages uploading of those writes to your backend using the `uploadData()` function that you defined in the [Client-Side Setup](/installation/client-side-setup/integrating-with-your-backend) part of the implementation. That `uploadData()` function should call your backend application API to apply the writes to your backend database. The reason why we designed PowerSync this way is to give you full control over things like data validation and authorization of writes, while PowerSync itself requires minimal permissions. 2. **Authentication integration:** Your backend is responsible for securely generating the [JWTs](/installation/authentication-setup) used by the PowerSync Client SDK to authenticate with the [PowerSync Service](/architecture/powersync-service). diff --git a/installation/app-backend-setup/writing-client-changes.mdx b/installation/app-backend-setup/writing-client-changes.mdx index 9e6babad..dc7c5e43 100644 --- a/installation/app-backend-setup/writing-client-changes.mdx +++ b/installation/app-backend-setup/writing-client-changes.mdx @@ -17,13 +17,13 @@ Since you get to define the client-side `uploadData()` function as you wish, you You can also use any API style you want — e.g. REST, GraphQL, gRPC, etc. -It's important that your API endpoint be blocking/synchronous with underlying writes to the backend database (Postgres, MongoDB or MySQL). +It's important that your API endpoint be blocking/synchronous with underlying writes to the backend database (Postgres, MongoDB, MySQL, or SQL Server). In other words, don't place writes into something like a queue for processing later — process them immediately. For more details, see the explainer below. -PowerSync uses a server-authoritative architecture with a checkpoint system for conflict resolution and [consistency](/architecture/consistency). The client advances to a new write checkpoint after uploads have been processed, so if the client believes that the server has written changes into your backend database (Postgres, MongoDB or MySQL), but the next checkpoint does not contain your uploaded changes, those changes will be removed from the client. This could manifest as UI glitches for your end-users, where the changes disappear from the device for a few seconds and then re-appear. +PowerSync uses a server-authoritative architecture with a checkpoint system for conflict resolution and [consistency](/architecture/consistency). The client advances to a new write checkpoint after uploads have been processed, so if the client believes that the server has written changes into your backend database (Postgres, MongoDB, MySQL, or SQL Server), but the next checkpoint does not contain your uploaded changes, those changes will be removed from the client. This could manifest as UI glitches for your end-users, where the changes disappear from the device for a few seconds and then re-appear. ### Write operations recorded on the client diff --git a/installation/client-side-setup/integrating-with-your-backend.mdx b/installation/client-side-setup/integrating-with-your-backend.mdx index abf43b01..84c95be3 100644 --- a/installation/client-side-setup/integrating-with-your-backend.mdx +++ b/installation/client-side-setup/integrating-with-your-backend.mdx @@ -7,7 +7,7 @@ After you've [instantiated](/installation/client-side-setup/instantiate-powersyn | Purpose | Description | |---------|-------------| -| **Uploading writes to your backend:** | Writes that are made to the client-side SQLite database are uploaded to your backend application, where you control how they're applied to your backend database (Postgres, MongoDB or MySQL). This is how PowerSync achieves bi-directional syncing of data. | +| **Uploading writes to your backend:** | Writes that are made to the client-side SQLite database are uploaded to your backend application, where you control how they're applied to your backend database (Postgres, MongoDB, MySQL, or SQL Server). This is how PowerSync achieves bi-directional syncing of data. | | **Authentication integration:** | PowerSync uses JWTs for authentication between the Client SDK and PowerSync Service. Your backend application should be able to generate JWTs that the PowerSync Client SDK can retrieve and use for authentication against your [PowerSync Service](/architecture/powersync-service) instance. | Accordingly, you must pass a _backend connector_ as an argument when you call `connect()` on the client-side PowerSync database. You must define that backend connector, and it must implement two functions/methods: diff --git a/installation/database-connection.mdx b/installation/database-connection.mdx index d29d4991..9d78efd8 100644 --- a/installation/database-connection.mdx +++ b/installation/database-connection.mdx @@ -228,3 +228,26 @@ For other providers and self-hosted databases: Make sure that your MySQL database allows access to PowerSync's IPs — see [Security and IP Filtering](/installation/database-setup/security-and-ip-filtering) +## SQL Server (Alpha) Specifics + +1. In the [PowerSync Dashboard](https://dashboard.powersync.com/), select your project and instance and go to the **Database Connections** view. +2. Click **Connect to Source Database** and ensure the **"SQL Server"** tab is selected. +3. Fill in your SQL Server connection details: + 1. "**Name**", "**Host**", "**Port**", "**Database name**", "**Username**", "**Password**" are required. + 2. "**Name**" can be any name for the connection. + 3. "**Host**" is the endpoint for your SQL Server instance. + 4. "**Port**" is typically 1433 for SQL Server (default port). + 5. "**Database name**" is the database where CDC is enabled. + 6. "**Username**" and "**Password**" maps to the database user created in [Source Database Setup](/installation/database-setup#sql-server-alpha) (e.g., `powersync_user`). +4. Click **Test Connection** and fix any errors. +5. Click **Save Connection**. + +PowerSync deploys and configures an isolated cloud environment for you, which can take a few minutes to complete. + + + Make sure that your SQL Server database allows access to PowerSync's IPs — see [Security and IP Filtering](/installation/database-setup/security-and-ip-filtering) + + +Also see: +- [SQL Server Setup](/installation/database-setup#sql-server-alpha) + diff --git a/installation/database-setup.mdx b/installation/database-setup.mdx index 2eb136f0..10869e25 100644 --- a/installation/database-setup.mdx +++ b/installation/database-setup.mdx @@ -4,7 +4,7 @@ description: "Configure your backend database for PowerSync, including permissio sidebarTitle: "Overview" --- -Jump to: [Postgres](#postgres) | [MongoDB](#mongodb) | [MySQL](#mysql-beta) +Jump to: [Postgres](#postgres) | [MongoDB](#mongodb) | [MySQL](#mysql-beta) | [SQL Server](#sql-server-alpha) import PostgresPowerSyncUser from '/snippets/postgres-powersync-user.mdx'; import PostgresPowerSyncPublication from '/snippets/postgres-powersync-publication.mdx'; @@ -399,6 +399,190 @@ binlog-do-db=invoices_db binlog-ignore-db=user_db ``` +## SQL Server (Alpha) + + + **Version compatibility**: PowerSync requires SQL Server 2022+ or Azure SQL Database. + + +PowerSync replicates data from SQL Server using Change Data Capture (CDC). This process builds up change tables based on changes to tracked tables. The change tables are populated by reading from the SQL Server transaction log on a fixed interval. PowerSync then polls these CDC tables for changes using built-in stored procedures. + +For more information about CDC, see: +- [Change Data Capture (SQL Server)](https://learn.microsoft.com/en-us/sql/relational-databases/track-changes/about-change-data-capture-sql-server) - for SQL Server +- [Change Data Capture (Azure SQL Database)](https://learn.microsoft.com/en-us/azure/azure-sql/database/change-data-capture-overview?view=azuresql) - for Azure SQL Database + +### Supported Editions/Versions + +| 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 subscription model. S3 tier and up on DTU purchasing model. | + +\* Azure SQL Database is always running on the latest version of the SQL Server DB Engine + +### Database Setup Requirements + +#### 1. Enable CDC on the Database + +Change Data Capture (CDC) needs to be enabled on the database: + +```sql +-- Enable CDC on the database if not already enabled +USE ; +IF (SELECT is_cdc_enabled FROM sys.databases WHERE name = '') = 0 +BEGIN + EXEC sys.sp_cdc_enable_db; +END +GO +``` + +#### 2. Create the PowerSync Checkpoints Table + +PowerSync requires a `_powersync_checkpoints` table to generate regular checkpoints. CDC must be enabled for this table: + +```sql +-- Create the PowerSync checkpoints table in your schema +IF OBJECT_ID('._powersync_checkpoints', 'U') IS NULL +BEGIN +CREATE TABLE ._powersync_checkpoints ( + id INT IDENTITY PRIMARY KEY, + last_updated DATETIME NOT NULL DEFAULT GETUTCDATE() +); +END + +-- Enable CDC for the powersync checkpoints table if not already enabled +-- Note: the cdc_reader role created the first time CDC is enabled on a table +IF NOT EXISTS (SELECT 1 FROM cdc.change_tables WHERE source_object_id = OBJECT_ID(N'._powersync_checkpoints')) +BEGIN + EXEC sys.sp_cdc_enable_table + @source_schema = N'', + @source_name = N'_powersync_checkpoints', + @role_name = N'cdc_reader', + @supports_net_changes = 0; +END +GO +``` + +#### 3. Enable CDC on Tables + +CDC must be enabled for all tables that need to be replicated: + +```sql +-- Enable CDC for specific tables in your schema if not already enabled +IF NOT EXISTS (SELECT 1 FROM cdc.change_tables WHERE source_object_id = OBJECT_ID(N'.')) +BEGIN + EXEC sys.sp_cdc_enable_table + @source_schema = N'', + @source_name = N'', + @role_name = N'cdc_reader', + @supports_net_changes = 0; +END +GO +``` + +Repeat this for each table you want to replicate. Note that PowerSync does not currently use the net changes functionality so `@supports_net_changes` can be set to `0`. + +#### 4. Create Database User + +Create a database user for PowerSync with the following permissions: + +**Required permissions:** +- Read/Write permissions on the `_powersync_checkpoints` table +- Read permissions on the replicated tables +- `cdc_reader` role (grants access to CDC tables and functions) +- `VIEW DATABASE PERFORMANCE STATE` (SQL Server and Azure SQL) +- `VIEW SERVER PERFORMANCE STATE` (SQL Server only) + +```sql +-- Create a SQL login for the powersync_user if missing. Note SQL Logins are created at the server level. +USE [master]; +IF NOT EXISTS (SELECT 1 FROM sys.server_principals WHERE name = '') +BEGIN + CREATE LOGIN [] WITH PASSWORD = 'YOUR_DB_USER_PASSWORD', CHECK_POLICY = ON; +END +GO + +-- Create a DB user for PowerSync if missing. Note DB users are created at the database level. +USE []; +IF NOT EXISTS (SELECT 1 FROM sys.database_principals WHERE name = '') +BEGIN + CREATE USER [] FOR LOGIN []; +END +GO + +-- Grant read/write access to the PowerSync checkpoints table +GRANT SELECT, INSERT, UPDATE ON ._powersync_checkpoints TO []; +GO + +-- Grant read access to all tables in the database using the db_datareader role (Less restrictive) +IF IS_ROLEMEMBER('db_datareader', '') = 0 +BEGIN + ALTER ROLE db_datareader ADD MEMBER ; +END +GO + +-- Grant access to CDC tables and functions using the cdc_reader role +IF IS_ROLEMEMBER('cdc_reader', '') = 0 +BEGIN + ALTER ROLE cdc_reader ADD MEMBER ; +END +GO + +-- Grant performance state permissions + +-- Note: For Azure SQL, only VIEW DATABASE PERFORMANCE STATE is required. Granted at the database level. +-- PowerSync uses this to access the sys.dm_db_log_stats DMV and the sys.dm_db_partition_stats DMV +USE []; +GRANT VIEW DATABASE PERFORMANCE STATE TO []; +GO + +-- VIEW SERVER PERFORMANCE STATE is only available on SQL Server (not Azure SQL). Granted at the server level. +-- PowerSync requires this permission to access the sys.dm_db_log_stats DMV on SQL Server. +USE [master]; +IF SERVERPROPERTY('EngineEdition') != 5 -- 5 = Azure SQL Database +BEGIN + GRANT VIEW SERVER PERFORMANCE STATE TO []; +END +GO +``` + +Alternatively, you can grant more granular permissions on specific tables: + +```sql +-- Grant SELECT on the specific replicated tables (recommended for more restrictive access) +GRANT SELECT ON . TO []; +``` + + + For Azure SQL Database, the `VIEW SERVER PERFORMANCE STATE` permission is not available and not required. Only `VIEW DATABASE PERFORMANCE STATE` is needed. + + +### CDC Management + +Management and performance turning of CDC is left to the developer and is primarily done by modifying the change capture jobs. See [Change Data Capture Jobs (SQL Server)](https://learn.microsoft.com/en-us/sql/relational-databases/track-changes/administer-and-monitor-change-data-capture-sql-server?view=sql-server-ver17) for more details. +Capture Job settings of interest to PowerSync: +- Polling interval: The frequency at which the capture job reads changes from the transaction log. Default is every 5 seconds. Can be set to 0 so that there is zero downtime between scans, but this will impact database performance. +- Max Trans: The maximum number of transactions that are processed per scan. Default is 500. +- Max Scans: The maximum number of scans that are performed per capture job scan cycle. Default is 10. + +Cleanup Job settings of interest to PowerSync: +- Retention: The retention period before data is expired from the CDC tables. Default is 3 days. If your PowerSync instance is offline for longer than this period, data will need to be fully re-synced. Specified in minutes. + +Recommended Capture Job settings: +| Parameter | Recommended Value | +|-------------------------|-------------------| +| maxtrans | 5000 | +| maxscans | 10 | +| pollinginterval| 1 second | + +### Limitations + +- For Azure SQL Database, the CDC capture and cleanup jobs are managed automatically. Manual configuration is greatly limited. +See: [Azure CDC Customization Limitations](https://learn.microsoft.com/en-us/azure/azure-sql/database/change-data-capture-overview?view=azuresql#cdc-customization) +The main limitation is that the capture job polling interval cannot be modified and is fixed at 20 seconds. It is, however, still possible to [manually trigger](https://learn.microsoft.com/en-us/azure/azure-sql/database/change-data-capture-overview?view=azuresql#manual-cdc-control) the capture job on demand. +- CDC can only be enabled on Azure SQL Databases on the vCore purchasing model, OR for database on the DTU purchasing model, only on the S3 tier and above. +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) + ## Next Step Next, connect PowerSync to your database: diff --git a/installation/database-setup/private-endpoints.mdx b/installation/database-setup/private-endpoints.mdx index 784d2934..2db85306 100644 --- a/installation/database-setup/private-endpoints.mdx +++ b/installation/database-setup/private-endpoints.mdx @@ -14,7 +14,7 @@ Do not rely on Private Endpoints as the only form of security. Always use strong ## Current Limitations -1. Private Endpoints are currently only supported for Postgres and MongoDB instances. [Contact us](/resources/contact-us) if you need this for MySQL. +1. Private Endpoints are currently only supported for Postgres and MongoDB instances. [Contact us](/resources/contact-us) if you need this for MySQL or SQL Server. 2. Self-service is not yet available on the PowerSync side — [contact PowerSync support](/resources/contact-us) to configure the instance. 3. Only AWS is supported currently — other cloud providers are not supported yet. 4. The **"Test Connection"** function on the [PowerSync Dashboard](https://dashboard.powersync.com/) is not supported yet - the instance has to be deployed to test the connection. diff --git a/installation/quickstart-guide.mdx b/installation/quickstart-guide.mdx index 73d62d9a..d04fe700 100644 --- a/installation/quickstart-guide.mdx +++ b/installation/quickstart-guide.mdx @@ -3,7 +3,7 @@ title: "Quickstart Guide / Installation Overview" sidebarTitle: "Quickstart / Overview" --- -PowerSync is designed to be stack agnostic, and currently supports [Postgres](/installation/database-setup#postgres), [MongoDB](/installation/database-setup#mongodb) and [MySQL](/installation/database-setup#mysql-beta) (Beta) as the backend source database, and has the following official client-side SDKs available: +PowerSync is designed to be stack agnostic, and currently supports [Postgres](/installation/database-setup#postgres), [MongoDB](/installation/database-setup#mongodb), [MySQL](/installation/database-setup#mysql-beta) (Beta), and [SQL Server](/installation/database-setup#sql-server-alpha) (Alpha) as the backend source database, and has the following official client-side SDKs available: - [**Dart/Flutter**](/client-sdk-references/flutter) (mobile and [web](/client-sdk-references/flutter/flutter-web-support)) - [**React Native**](/client-sdk-references/react-native-and-expo) (mobile and [web](/client-sdk-references/react-native-and-expo/react-native-web-support)) - [**JavaScript Web**](/client-sdk-references/javascript-web) (including integrations for React, Vue and TanStack) diff --git a/integration-guides/coolify.mdx b/integration-guides/coolify.mdx index 7ec560d7..432bd8bb 100644 --- a/integration-guides/coolify.mdx +++ b/integration-guides/coolify.mdx @@ -122,7 +122,7 @@ The following configuration options should be updated: PS_DATABASE_TYPE - postgresql OR mongodb OR mysql + postgresql OR mongodb OR mysql OR SQL Server PS_DATABASE_URI diff --git a/intro/powersync-overview.mdx b/intro/powersync-overview.mdx index bc155114..214a59be 100644 --- a/intro/powersync-overview.mdx +++ b/intro/powersync-overview.mdx @@ -17,12 +17,14 @@ It lets you avoid the complexities of using APIs to move app state [over the net PowerSync is designed to be backend database agnostic, and currently supports: - + + + ### Supported Client SDKs diff --git a/intro/powersync-philosophy.mdx b/intro/powersync-philosophy.mdx index 9208bd6a..837d5239 100644 --- a/intro/powersync-philosophy.mdx +++ b/intro/powersync-philosophy.mdx @@ -13,7 +13,7 @@ The app is always [fast and responsive](https://www.powersync.com/blog/local-fir PowerSync lets you avoid the complexities of using APIs to move app state [over the network](https://www.powersync.com/blog/escaping-the-network-tarpit). Its goal is to solve the hard problems of keeping data in sync, without getting in your way. -You use a standard Postgres, MongoDB or MySQL \[[1](#footnotes)\] database on the server, a standard SQLite database on the client, and your [own backend](/installation/app-backend-setup) to process writes. PowerSync simply keeps the SQLite database in sync with your backend/server database. +You use a standard Postgres, MongoDB, MySQL, or SQL Server \[[1](#footnotes)\] database on the server, a standard SQLite database on the client, and your [own backend](/installation/app-backend-setup) to process writes. PowerSync simply keeps the SQLite database in sync with your backend/server database. #### State Management @@ -38,7 +38,7 @@ Our goal is also to be stack-agnostic: whether you are switching from MySQL to P #### Simplicity -You use plain Postgres, MongoDB or MySQL on the server — no extensions, and no significant change in your schema required \[[2](#footnotes)\]. PowerSync [uses](/installation/database-setup) Postgres logical replication, MongoDB change streams or the MySQL binlog to replicate changes to the [PowerSync Service](/architecture/powersync-service), where data is transformed and partitioned according to [Sync Rules](/usage/sync-rules), and persisted in a way that allows efficiently streaming incremental changes to each client. +You use plain Postgres, MongoDB, MySQL, or SQL Server on the server — no extensions, and no significant change in your schema required \[[2](#footnotes)\]. PowerSync [uses](/installation/database-setup) Postgres logical replication, MongoDB change streams, MySQL binlog, or SQL Server Change Data Capture (CDC) to replicate changes to the [PowerSync Service](/architecture/powersync-service), where data is transformed and partitioned according to [Sync Rules](/usage/sync-rules), and persisted in a way that allows efficiently streaming incremental changes to each client. PowerSync has been used in apps with hundreds of tables. There are no complex migrations to run: You define your [Sync Rules](/usage/sync-rules) and [client-side schema](/installation/client-side-setup/define-your-schema), and the data is automatically kept in sync. If you [change Sync Rules](/usage/lifecycle-maintenance/implementing-schema-changes), the entire new set of data is applied atomically on the client. When you do need to make schema changes on the server while still supporting older clients, we [have the processes in place](/usage/lifecycle-maintenance/implementing-schema-changes) to do that without hassle. diff --git a/resources/usage-and-billing/usage-and-billing-faq.mdx b/resources/usage-and-billing/usage-and-billing-faq.mdx index 67c4c20c..fdd886f4 100644 --- a/resources/usage-and-billing/usage-and-billing-faq.mdx +++ b/resources/usage-and-billing/usage-and-billing-faq.mdx @@ -74,7 +74,7 @@ description: "Usage and billing FAQs and troubleshooting strategies." Data processing was calculated as the total uncompressed size of data replicated from your source database(s) to PowerSync Service instances, plus data synced from PowerSync Service instances to user devices. These values are still available in your [Usage metrics](/usage/tools/monitoring-and-alerting#usage-metrics) as "Data replicated per day/hour" and "Data synced per day/hour". - Data replicated refers to activity from your backend database (Postgres/MongoDB or MySQL database) to the PowerSync Service — this is not billed. + Data replicated refers to activity from your backend database (Postgres, MongoDB, MySQL, or SQL Server database) to the PowerSync Service — this is not billed. Data synced refers to data streamed from the PowerSync Service to client devices — this is used for billing. diff --git a/usage/sync-rules.mdx b/usage/sync-rules.mdx index c97e18b8..ee12315b 100644 --- a/usage/sync-rules.mdx +++ b/usage/sync-rules.mdx @@ -26,11 +26,8 @@ We encourage you to explore Sync Streams for new projects, and migrating to Sync ## Defining Sync Rules -Each [PowerSync Service](/architecture/powersync-service) instance has a Sync Rules configuration where Sync Rules are defined using SQL-like queries (limitations and more info [here](/usage/sync-rules/operators-and-functions)) combined together in a YAML file. - -This SQL-like syntax is used when connecting to either Postgres, MongoDB or MySQL as the backend source database. - -The [PowerSync Service](/architecture/powersync-service) uses these SQL-like queries to group data into "sync buckets" when replicating data to client devices. +Each [PowerSync Service](/architecture/powersync-service) instance has a Sync Rules configuration where Sync Rules are defined using SQL-like queries (limitations and more info [here](/usage/sync-rules/operators-and-functions)) combined together in a YAML file. +The Service uses these SQL-like queries to group data into "sync buckets" when replicating data from your backend source database to client devices. diff --git a/usage/sync-rules/advanced-topics/sharded-databases.mdx b/usage/sync-rules/advanced-topics/sharded-databases.mdx index b9bf1201..157059a5 100644 --- a/usage/sync-rules/advanced-topics/sharded-databases.mdx +++ b/usage/sync-rules/advanced-topics/sharded-databases.mdx @@ -8,7 +8,7 @@ In the case of Postgres, PowerSync cannot replicate Postgres [foreign tables](ht However, PowerSync does have options available to support sharded databases in general. - When using MongoDB or MySQL as the backend source database, PowerSync does not currently support connecting to sharded clusters. + When using MongoDB, MySQL, or SQL Server as the backend source database, PowerSync does not currently support connecting to sharded clusters. The primary options are: diff --git a/usage/sync-rules/types.mdx b/usage/sync-rules/types.mdx index 430ec0a4..b27174a9 100644 --- a/usage/sync-rules/types.mdx +++ b/usage/sync-rules/types.mdx @@ -95,7 +95,7 @@ MySQL values are mapped according to this table: | year | text | | | json | text | There is no dedicated JSON type — JSON functions operate directly on text values. | | binary, varbinary | blob | See note below regarding binary types | -| blob, tinyblob, mediumblob, longblob | blob | | +| image | blob | | | geometry, geometrycollection | blob | | | point, multipoint | blob | | | linestring, multilinestring | blob | | @@ -105,3 +105,33 @@ MySQL values are mapped according to this table: Binary data can be accessed in the Sync Rules, but cannot be used as bucket parameters. Before it can be synced directly to clients it needs to be converted to hex or base64 first. See [Operators & Functions](/usage/sync-rules/operators-and-functions) + +## SQL Server (Alpha) Type Mapping + +SQL Server values are mapped according to this table: + +| SQL Server Data Type | PowerSync / SQLite Column Type | Notes | +|----------------------------------------------------|--------------------------------|--------------------------------------------------------| +| tinyint, smallint, int, bigint | integer | | +| numeric, decimal | text | Numeric string | +| float, real | real | | +| bit | integer | | +| money, smallmoney | text | Numeric string | +| xml | text | | +| char, nchar, ntext | text | | +| varchar, nvarchar, text | text | | +| uniqueidentifier | text | | +| timestamp | text | ISO 8061 format: `YYYY-MM-DDTHH:mm:ss.sssZ` | +| date | text | Format: `YYYY-MM-DD` | +| time | text | Format: `HH:mm:ss.sss` | +| datetime, datetime2, smalldatetime, datetimeoffset | text | ISO 8061 format: `YYYY-MM-DDTHH:mm:ss.sssZ` | +| json | text | Only exists for Azure SQL Database and SQL Server 2025 | +| geometry, geography | text | Text of JSON object describing the spatial data type | +| binary, varbinary, image | blob | See note below regarding binary types | +| rowversion, timestamp | blob | See note below regarding binary types | +| User Defined Types: hiearchyid | blob | See note below regarding binary types | + + + Binary data can be accessed in the Sync Rules, but cannot be used as bucket parameters. Before it can be synced directly to clients it needs to be converted to hex or base64 first. + See [Operators & Functions](/usage/sync-rules/operators-and-functions) + \ No newline at end of file