feat: Convex docs

.github/vale/config/vocabularies/PowerSync/accept.txt

@@ -236,6 +236,7 @@ CloudWatch
 Cocoapods
 Cognito
 Coolify
+Convex
 cron
 CSQLite
 Cursor
@@ -310,4 +311,4 @@ Yjs
 Zod
 
 # Package names
-drift_sqlite_async
+drift_sqlite_async

architecture/powersync-service.mdx

@@ -3,7 +3,7 @@ title: "PowerSync Service"
 description: "Understand the PowerSync Service architecture and how it replicates data and delivers real-time sync."
 ---
 
-When we say "PowerSync instance" we are referring to an instance of the [PowerSync Service](https://github.com/powersync-ja/powersync-service), which is the server-side component of the sync engine responsible for the _read path_ from the source database to client-side SQLite databases: The primary purposes of the PowerSync Service are (1) replicating data from your source database (Postgres, MongoDB, MySQL, SQL Server), and (2) streaming data to clients. Both of these happen based on your [Sync Streams](/sync/streams/overview) (or legacy [Sync Rules](/sync/rules/overview)).
+When we say "PowerSync instance" we are referring to an instance of the [PowerSync Service](https://github.com/powersync-ja/powersync-service), which is the server-side component of the sync engine responsible for the _read path_ from the source database to client-side SQLite databases: The primary purposes of the PowerSync Service are (1) replicating data from your source database (Postgres, MongoDB, MySQL, SQL Server or Convex), and (2) streaming data to clients. Both of these happen based on your [Sync Streams](/sync/streams/overview) (or legacy [Sync Rules](/sync/rules/overview)).
 
 
 ## Bucket System
@@ -62,7 +62,7 @@ When a change occurs in the source database that affects a certain bucket (based
 
 ## Bucket Storage
 
-The PowerSync Service persists the bucket state in durable storage: there is a pluggable storage layer for bucket data, and MongoDB and Postgres are currently supported as _bucket storage_ databases. The _bucket storage_ database is separate from the connection to your _source database_ (Postgres, MongoDB, MySQL or SQL Server). Our cloud-hosting offering (PowerSync Cloud) uses MongoDB Atlas as the _bucket storage_ database.
+The PowerSync Service persists the bucket state in durable storage: there is a pluggable storage layer for bucket data, and MongoDB and Postgres are currently supported as _bucket storage_ databases. The _bucket storage_ database is separate from the connection to your _source database_ (Postgres, MongoDB, MySQL, SQL Server or Convex). Our cloud-hosting offering (PowerSync Cloud) uses MongoDB Atlas as the _bucket storage_ database.
 
 Persisting the bucket state in a database is also part of how PowerSync achieves high scalability: it means that the PowerSync Service can have a low memory footprint even as you scale to very large volumes of synced data and users/clients.
 
@@ -87,7 +87,7 @@ When the PowerSync Service replicates data from the source database, it:
 
 Whenever a new version of Sync Streams/Sync Rules is deployed, initial replication takes place by means of taking a snapshot of all tables/collections they reference.
 
-After that, data is incrementally replicated using a change data capture stream (the specific mechanism depends on the source database type: Postgres logical replication, MongoDB change streams, the MySQL binlog, or SQL Server Change Data Capture).
+After that, data is incrementally replicated using a change data capture stream. The specific mechanism depends on the source database type: Postgres logical replication, MongoDB change streams, the MySQL binlog, SQL Server Change Data Capture, or Convex document deltas.
 
 
 ## Streaming Sync
@@ -111,4 +111,3 @@ For more details on exactly how streaming sync works, see [PowerSync Protocol](/
 The repo for the PowerSync Service can be found here:
 
 <Card title="GitHub - powersync-service" horizontal icon="github" href="https://github.com/powersync-ja/powersync-service" />
-

configuration/app-backend/client-side-integration.mdx

@@ -10,7 +10,7 @@ After you've [instantiated](/intro/setup-guide#instantiate-the-powersync-databas
 
 | Purpose | Description |
 |---------|-------------|
-| **Uploading mutations to your backend:** | Mutations 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 source database (Postgres, MongoDB, MySQL, or SQL Server). This is how PowerSync achieves bi-directional syncing of data: The [PowerSync Service](/architecture/powersync-service) provides the _server-to-client read path_ based on your [Sync Streams or Sync Rules (legacy)](/sync/overview), and the _client-to-server write path_ goes via your backend. |
+| **Uploading mutations to your backend:** | Mutations 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 source database (Postgres, MongoDB, MySQL, SQL Server, or Convex). This is how PowerSync achieves bi-directional syncing of data: The [PowerSync Service](/architecture/powersync-service) provides the _server-to-client read path_ based on your [Sync Streams or Sync Rules (legacy)](/sync/overview), and the _client-to-server write path_ goes via your backend. |
 | **Authentication integration:** (optional) | PowerSync uses JWTs for authentication between the Client SDK and PowerSync Service. Some [authentication providers](/configuration/auth/overview#common-authentication-providers) generate JWTs for users which PowerSync can verify directly. For others, some code must be [added to your application backend](/configuration/auth/custom) to generate the JWTs. |
 
 
@@ -180,4 +180,3 @@ For an example implementation of a PowerSync 'backend connector', see the SDK gu
 ## More Examples
 
 For additional implementation examples, see the [Examples](/intro/examples) section.
-

configuration/app-backend/setup.mdx

@@ -8,7 +8,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 potential purposes:
 
-1. **Allowing client-side mutations to be uploaded** and [applied](/handling-writes/writing-client-changes) to the backend source database (Postgres, MongoDB, MySQL, or SQL Server). When you write to the client-side SQLite database provided by PowerSync, those mutations are also placed into an [upload queue](/architecture/client-architecture#writing-data-via-sqlite-database-and-upload-queue). The PowerSync Client SDK manages uploading of those mutations to your backend using the `uploadData()` function that you define in your [client-side](/configuration/app-backend/client-side-integration) _backend connector_ implementation. Your `uploadData()` implementation should call your backend application API to apply the mutations to your source database. The reason why we designed PowerSync this way is to give you full control over things like server-side data validation and authorization of mutations, while PowerSync itself requires minimal permissions.
+1. **Allowing client-side mutations to be uploaded** and [applied](/handling-writes/writing-client-changes) to the backend source database (Postgres, MongoDB, MySQL, SQL Server, or Convex). When you write to the client-side SQLite database provided by PowerSync, those mutations are also placed into an [upload queue](/architecture/client-architecture#writing-data-via-sqlite-database-and-upload-queue). The PowerSync Client SDK manages uploading of those mutations to your backend using the `uploadData()` function that you define in your [client-side](/configuration/app-backend/client-side-integration) _backend connector_ implementation. Your `uploadData()` implementation should call your backend application API to apply the mutations to your source database. The reason why we designed PowerSync this way is to give you full control over things like server-side data validation and authorization of mutations, while PowerSync itself requires minimal permissions.
 2. **Authentication integration (optional):** _If_ you are implementing custom authentication (see below), your backend is responsible for securely generating the [JWTs](/configuration/auth/overview) used by the PowerSync Client SDK to authenticate with the [PowerSync Service](/architecture/powersync-service).
 
 If you will only use the backend for applying mutations and not for authentication, you can also use some kind of data API service or API platform (e.g. Hasura).
@@ -56,4 +56,4 @@ You can use a serverless functions system like Azure Functions, AWS Lambda, Goog
 
 ### <Icon icon="leaf" iconType="solid" size={25} /> For MongoDB: PowerSync Hosted/Managed Option
 
-For developers using MongoDB as a backend source database, an alternative option is to use CloudCode, a serverless cloud functions environment provided by a sibling product of PowerSync, that runs in the same cloud environment as PowerSync Cloud. We have a template that you can use as a turnkey starting point. See the [documentation](/configuration/app-backend/cloudcode).
+For developers using MongoDB as a backend source database, an alternative option is to use CloudCode, a serverless cloud functions environment provided by a sibling product of PowerSync, that runs in the same cloud environment as PowerSync Cloud. We have a template that you can use as a turnkey starting point. See the [documentation](/configuration/app-backend/cloudcode).

configuration/source-db/connection.mdx

@@ -1,13 +1,13 @@
 ---
 title: "Source Database Connection"
-description: "Connect a PowerSync Cloud instance to your Postgres, MongoDB, MySQL or SQL Server source database."
+description: "Connect a PowerSync Cloud instance to your Postgres, MongoDB, MySQL, SQL Server or Convex source database."
 ---
 
 import SupabaseConnection from '/snippets/supabase-database-connection.mdx';
 
 Each database provider has their quirks when it comes to specifying connection details, so we have documented database-specific and provider-specific instructions below:
 
-Jump to: [Postgres](#postgres-provider-specifics) | [MongoDB](#mongodb-specifics) | [MySQL](#mysql-specifics) | [SQL Server](#sql-server-specifics)
+Jump to: [Postgres](#postgres-provider-specifics) | [MongoDB](#mongodb-specifics) | [MySQL](#mysql-specifics) | [SQL Server](#sql-server-specifics) | [Convex](#convex-specifics)
 
 <Note>The below instructions are currently written for PowerSync Cloud. For self-hosted PowerSync instances, specify database connection details in the config file as documented [here](/configuration/powersync-service/self-hosted-instances#source-database-connections).</Note>
 
@@ -128,7 +128,7 @@
 <Accordion title="Xata">
 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 **Postgres** tab is selected.
 3. In your Xata dashboard, navigate to Overview -> Connect and copy the connection URI. Alternatively, use the [Xata CLI](https://xata.io/docs/cli) and run `xata branch url` to obtain the URI and copy that.
 4. Paste the connection details into the "**URI**" field in the PowerSync Dashboard.
 5. Click **Test Connection** and fix any errors.
 6. Click **Save Connection**.
@@ -279,4 +279,29 @@
 </Info>
 
 Also see:
-- [SQL Server Source Database Setup](/configuration/source-db/setup#sql-server)
+- [SQL Server Source Database Setup](/configuration/source-db/setup#sql-server)
+
+
+## <Icon icon="database" iconType="solid" size={32}/> Convex Specifics
+
+<Note>Convex support is currently in an [Open Alpha release](/resources/feature-status).</Note>
+
+Before connecting PowerSync, add the required `powersync_checkpoints` table and mutation to your Convex deployment. See [Convex Source Database Setup](/configuration/source-db/setup#convex).
+
+1. In the [PowerSync Dashboard](https://dashboard.powersync.com/), select your project and instance and go to **Database Connections**.
+2. Click **Connect to Source Database** and ensure the **Convex** tab is selected.
+3. Fill in your Convex connection details:
+   1. **Deployment URL** is your Convex deployment URL, for example `https://<your-deployment>.convex.cloud`.
+   2. **Deploy key** is the deploy key for the Convex deployment. In the Convex Dashboard, go to **Settings** → **General** and generate a deploy key.
+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.
+
+<Warning>
+  Convex deploy keys grant full read and write access to your Convex data. Use a deploy key for the correct environment, store it as a secret, and rotate it if it is exposed.
+</Warning>
+
+Also see:
+- [Convex Source Database Setup](/configuration/source-db/setup#convex)
+- [Type Mapping](/sync/types#convex-type-mapping)