Overview
If you already have Postgres or MySQL, start with live-read. Synapsor reads selected tables or views on demand through least-privilege credentials when a reviewed capability runs.
Write proposals are a separate safety layer. Synapsor stores the proposed change, evidence, approval, idempotency key, audit trail, and Synapsor review branch. A trusted worker in your environment applies approved writes back to your existing database.
Two credentials, two phases: Synapsor uses a read-only source credential for governed reads. It does not use that credential to update Postgres or MySQL. Approved proposals are applied later by your backend worker with your separate write credential.
CDC/mirrored subsets are private preview/hardening work. They use database change logs to keep selected Synapsor mirror rows current, but they are not customer-production supported until production-readiness signoff is approved.
Live-read external mappings are the public connector path today. Use read-only credentials, safe views, tenant filters, allowed columns, evidence, and query audit before adding any writeback flow.
Your existing database remains the source of truth for application tables. Synapsor stores the agent contract, imported mapping metadata, evidence lookup records, query audit, proposals, approval/settlement records, replay records, and writeback status.
What stays in your database
Your application tables, existing transactions, normal app writes, ORM migrations, indexes, backups, replicas, and direct operational ownership stay with Postgres or MySQL.
For writeback, the trusted worker applies approved changes using your database connection, tenant guards, primary-key guards, optional conflict guards, and normal transaction rules.
What Synapsor stores
Synapsor stores source metadata, selected table/view mappings, allowed and denied columns, tenant-column rules, capability/workflow definitions, query audit, evidence bundles, Synapsor review branches, write proposals, approvals, settlement events, replay records, and writeback status.
Connection secrets are stored through the secret abstraction and are not returned in public API responses. The model never receives a database URL or raw SQL write tool.
Choose the safe path first
Most teams should start with live-read, then add proposal writeback only after evidence and tenant filters are reviewed.
- Read-only evidence mode
- Review-branch proposal mode
- Trusted worker writeback mode
- Read-only DB user
- Safe views preferred
- Evidence and query audit
- CDC mirrored subsets
- Customer production change-log capture
- Replication slot/binlog lifecycle promises
- Lag/backpressure production SLOs
- CDC restore/replay signoff
- CDC customer rollout
Developer notes
- Use live-read first for existing Postgres/MySQL.
- Use read-only credentials and safe views.
- Treat write proposals as a reviewed writeback workflow, not direct model writes.
- Treat CDC/mirrored subsets as private preview only.
- Do not connect sensitive production data until your security and operator posture are reviewed.