Synapsor
Log inGet access
All docs
Docs
Getting Started

Production-oriented single-node architecture for existing databases

Current Synapsor Cloud is controlled beta. The production-oriented architecture keeps Postgres/MySQL as source of truth and uses Synapsor for contracts, evidence, proposals, replay, and audit.

Overview

The current hosted product is controlled beta. This page describes the production-oriented single-node architecture Synapsor is building toward for teams that already run Postgres or MySQL.

The core architecture is intentionally conservative: keep your existing database, ORM, migrations, transactions, and normal application writes. Use Synapsor as the trust layer for agent reads, evidence, proposals, approvals, replay, and audit.

The current connector path is live-read external mappings by default. Synapsor reads selected rows and columns through least-privilege credentials at capability runtime, records evidence/query audit, and keeps risky writes out of direct model access.

Approved writes back to the existing database should run through a trusted worker in your environment. Synapsor stores the proposal, evidence, approval, idempotency key, and audit trail; the worker applies parameterized updates using your existing database transaction rules.

This is not a claim of HA, serverless, horizontal scaling, compliance certification, or mission-critical SLA. Those claims require separate implementation, operating history, and review.

Known limitationsExisting DB quickstartExisting DB securityProposal writeback

Production-oriented existing DB boundary

Your application database remains the source of truth. Synapsor adds the agent-facing contract and durable review record.

Existing app and database keep
  • Postgres/MySQL source of truth
  • ORM and migrations
  • Normal user transactions
  • Application write path
  • Database backups/replicas you already operate
Synapsor adds
  • Reviewed agent workflows
  • Trusted SESSION bindings
  • Allowed columns and tenant filters
  • Evidence and query audit
  • Branch-staged proposals
  • Approval/settlement records
  • Replayable run graph

Developer notes

  • Use staging or a least-privilege read-only replica/view before connecting sensitive production data.
  • Keep your existing database as source of truth.
  • Use live-read mappings for the current connector path.
  • Use proposal writeback only after the read-only flow works and evidence/audit look correct.
  • Treat CDC/mirrored subsets as private preview/dev-test primitives until production monitoring, cleanup, restore semantics, and operator signoff are approved.