[gjtorikian]

Summary

• Two new provider guides, docs/integrations/planetscale.md (Postgres and Vitess) and docs/integrations/mongodb-atlas.md, in the shape of the Neon guide: create the database, pick a role or password, choose a connection, TLS, verify the endpoint, run the sync, query it.
• They record what each console actually required when the destinations were run against these providers on November 6, 2026, rather than what their docs promise: the PlanetScale role that can CREATE SCHEMA (the suggested one cannot), the libpq-only sslrootcert=system parameter that makes Node's pg fail with ENOENT, that a Vitess branch is the database so WORKOS_SYNC_SCHEMA must name it, PlanetScale's proxy-terminated TLS, and which Atlas role the sync needs (readWrite, plus dbAdmin only for init --repair) versus the one the test suite needs (Atlas admin, because it drops databases).
• Verification results are stated with their caveats: the Postgres compatibility suite passed on PlanetScale; the Vitess lifecycle passed through the CLI since the MySQL suite cannot create databases there; the MongoDB suite passed on Atlas except for two tests that assume a local server.
• All three guides move to docs/integrations/ so the documentation has one tree, and the README's integration list points there.

[greptile-apps]

Confidence Score: 4/5

[Low impact] The PR changes provider documentation and guide links, not sync behavior.

The Vitess upgrade instructions still need correction before merging.

Findings

1.  Vitess upgrades cannot finish ▶

Fix with agent prompt

### Issue 1
docs/integrations/planetscale.md:226-227
On a Vitess branch with safe migrations enabled, these steps cannot add a newly introduced column. `init --print-sql` prints complete table definitions, not changes to existing tables. The follow-up `init` executes the missing column's `ALTER TABLE` instead of reporting SQL to apply. PlanetScale rejects that change outside a deploy request, so the upgraded sync cannot start.

Document running the upgraded `init` on a development branch and deploying its schema changes before restarting production.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Summary

Adds PlanetScale and MongoDB Atlas setup guides and moves the Neon guide into docs/integrations/.

• PlanetScale Postgres can host the sync mirror using its regular database connection.
• PlanetScale Vitess can host the sync mirror inside its branch database.
• Sync operators can connect the mirror to a MongoDB Atlas cluster.
• The README lists all provider guides together under docs/integrations/.

_{Reviews (2) · Last reviewed commit: "docs: Keep the Vitess examples from clea..." · Reviewed by Greptile}

[greptile-apps]

Vitess upgrades cannot finish

On a Vitess branch with safe migrations enabled, these steps cannot add a newly introduced column. init --print-sql prints complete table definitions, not changes to existing tables. The follow-up init executes the missing column's ALTER TABLE instead of reporting SQL to apply. PlanetScale rejects that change outside a deploy request, so the upgraded sync cannot start.

Document running the upgraded init on a development branch and deploying its schema changes before restarting production.

Knowledge Base Used: MySQL storage destination

Prompt To Fix With AI

This is a comment left during a code review.
Path: docs/integrations/planetscale.md
Line: 222-223

Comment:
**Vitess upgrades cannot finish**

On a Vitess branch with safe migrations enabled, these steps cannot add a newly introduced column. `init --print-sql` prints complete table definitions, not changes to existing tables. The follow-up `init` executes the missing column's `ALTER TABLE` instead of reporting SQL to apply. PlanetScale rejects that change outside a deploy request, so the upgraded sync cannot start.

Document running the upgraded `init` on a development branch and deploying its schema changes before restarting production.

**Knowledge Base Used:** [MySQL storage destination](https://app.greptile.com/-/switch-tenant?tenant=workos&next=%2Fcustom-context%2Fknowledge-base%2Fworkos%2Fsync-engine%2F-%2Fdocs%2Fmysql-storage.md)

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.