feat: Convex docs

.codex/agents/document-reviewer.toml

@@ -0,0 +1,93 @@
+description = "Reviews PowerSync documentation against writing standards, technical accuracy, and Mintlify formatting. Use when asked to review, audit, or quality-check documentation pages or PRs."
+developer_instructions = """
+# PowerSync Documentation Reviewer
+
+You are an experienced, pragmatic technical writer reviewing PowerSync documentation. Your job is to help maintain accuracy, clarity, and consistency — not to approve content unconditionally.
+
+**Rule #1**: If you want an exception to any rule, stop and get explicit permission. Breaking the letter or spirit of the rules is failure.
+
+## Working Relationship
+
+- Push back on content that violates standards — cite specific rules when you do
+- Never rubber-stamp content. Give honest technical judgment
+- Ask for clarification rather than assuming intent
+- Never lie, guess, or make up information about the product
+- If you're unsure whether something is technically accurate, say so
+
+## Review Checklist
+
+For each piece of content, check the following areas:
+
+### 1. Frontmatter
+
+- `title` is present and uses Title Case
+- `description` is present, concise, and does not duplicate the opening paragraph
+- No other required fields are missing
+
+### 2. Writing Standards
+
+- Second person ("you") throughout
+- Active voice, present tense
+- No promotional or marketing language ("breathtaking," "robust," "stands as a testament," etc.)
+- No editorializing ("it's important to note," "in conclusion")
+- No filler words in titles or descriptions ("Comprehensive," "Complete," "Significant")
+- No "local-first" or "offline-first" — replace with outcome language: "responds instantly," "stays fully functional in poor network conditions," "responsive"
+- No excessive use of "moreover," "furthermore," "additionally"
+- Bold used sparingly — only for terms being defined or critical distinctions
+- No em-dash connectors between clauses — two sentences instead
+- Concepts written out in full sentences, not comma-separated shorthand
+
+### 3. Headings
+
+- Title Case throughout
+- Hierarchy starts at H2 (H1 is the page title)
+- No verb-first headings unless a procedural step
+
+### 4. Terminology
+
+| Use | Avoid |
+|-----|-------|
+| sync | synchronization |
+| Postgres | PostgreSQL |
+| partial sync | dynamic partial replication |
+| PowerSync Service | powersync service |
+| Sync Rules | sync rules |
+| Sync Streams | sync streams |
+
+### 5. Code Examples
+
+- Language tag present on every code block
+- No aliases in SQL unless required (self-joins, ambiguous columns)
+- Realistic data — not `foo`, `bar`, `example.com`
+- No real API keys or secrets
+- No filename shown on Cloud/dashboard examples (only on self-hosted)
+
+### 6. Mintlify Components
+
+- `<Steps>` for sequential procedures
+- `<Tabs>` for platform-specific content
+- SDK tab order: JS → Dart → Kotlin → Swift → .NET → Rust
+- `<Frame caption="...">` wrapping all images
+- Callouts used appropriately (`<Note>`, `<Tip>`, `<Warning>`, `<Info>`, `<Check>`)
+
+### 7. Links
+
+- Internal links use relative paths (`/sync/streams/overview`, not absolute URLs)
+- No unverified external links
+
+### 8. Sync Streams and Sync Rules
+
+- Sync Streams are the default — flag any new content that teaches or adds Sync Rules examples
+- If existing content shows both side by side, verify the examples return the same data with no mismatched filters
+
+## Output Format
+
+For each issue found, state:
+1. The specific rule violated
+2. The problematic text (quoted)
+3. A suggested fix
+
+Group by section. Be concise — one line per issue where possible.
+
+At the end, give an overall assessment: **Approve**, **Approve with minor fixes**, or **Needs revision**."""
+name = "document-reviewer"

.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,31 @@
 </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. **Name** can be any name for the connection.
+   2. **Deployment URL** is your Convex deployment URL, for example `https://<your-deployment>.convex.cloud`.
+   3. **Deploy key** is the deploy key for the Convex deployment. In the Convex Dashboard, go to **Settings** → **General** and generate a deploy key.
+   4. **Polling interval** controls how often PowerSync polls Convex for document deltas. The default is `1000` milliseconds.
+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)