Architecture overview

Each SQLStyle node has a SQLite database on local disk. Opening that database starts the per-database runtime inside the application process; SQL queries do not go through a SQLStyle proxy or the hosted controller. If several processes open the same database on one machine, they coordinate as one node and elect one local process to run capture and network services.

SQLStyle ships with the Bedrock database core: patched SQLite with WAL2. Its capture adapter publishes committed pages as SQLStyle transaction events, so replication and backup share one implementation after capture.

Capture creates one physical history

The primary’s database core publishes a committed WAL position while it still holds the native writer lock. Capture reads the corresponding pages, encodes each as either a compact difference from the preceding database view or a complete LZ4-compressed page, and publishes the records to a bounded shared-memory ring.

That ring feeds two paths:

    Bedrock build
        |
        v
  WAL page capture
        |
        v
  shared capture ring
      /       \
     v         v
replication   DBH history
     |         |
     v         v
 replicas    local catalog -> object storage

Replication sends captured transactions directly from the primary to each replica. DBH generation persists the same physical history into append-only segments. Local DBH extends replica catch-up beyond the ring; uploaded DBH and full snapshots form the recovery history used by restore.

The capture path also protects its source. Per-WAL requested and completed frontiers prevent checkpoint, restart, truncation, or WAL reuse from destroying frames before their ring records have been published.

Data and coordination cross different boundaries

Boundary	What crosses it
Database core to capture	Committed WAL positions and page data
Primary to replica	Captured transactions and, when required, an rsync snapshot
Node to object storage	Full snapshots and incremental DBH objects
Controller to node	Primary grants, topology, health decisions, and accepted recovery state

Application queries, replication pages, and backup objects never pass through the controller. Object-storage credentials also remain with the application runtime and recovery tools.

Authority is independent of local ownership

The controller grants one node primary authority and associates the grant with a fencing token. A newer token supersedes every earlier token, so a former primary cannot resume writes merely because its local database is recent or its process is still running.

The same lineage governs recovery. Objects uploaded by a former primary may remain in customer-owned storage, but stale authority cannot make those objects part of the accepted recovery chain. During failover, an eligible node must cover the controller’s required transaction before it can receive the next primary grant.

Local process ownership is narrower. A capture host may be replaced by another process on the same machine while the existing controller grant remains valid; that handoff preserves authority but cannot create or extend it.

Read the architecture by subsystem

1. Database core and capture explains the common capture contract, WAL-retention fence, page encodings, ring publication, and DBH handoff.
2. Node capabilities explains the independent controller permissions, capture policy, and capture-loss action.
3. Replication and catch-up covers live delivery, replica acknowledgements, local DBH catch-up, ring pressure, and rsync replacement.
4. Backup and recovery history follows DBH from a sealed local file through object storage, controller acceptance, retention, and restore planning.
5. Multi-process operation describes local ownership, presence, same-boot capture-owner replacement, and terminal cleanup.
6. Standard, Permissive, and Lightspeed integrity modes defines per-connection synchronous policy and clean-close proof before local reuse.
7. Primary authority and failover explains direct health evidence, controller confirmation, candidate recovery, and token transfer.