---
title: "Architecture overview"
description: "See where SQLStyle runs, what capture publishes, and how replication, backup history, and controller authority fit together."
section: "Architecture"
source_url: "https://sqlstyle.com/docs/architecture"
---
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:

```text
    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](/docs/database-cores-and-capture) explains the
   common capture contract, WAL-retention fence, page encodings, ring
   publication, and DBH handoff.
2. [Node capabilities](/docs/node-roles) explains the independent controller
   permissions, capture policy, and capture-loss action.
3. [Replication and catch-up](/docs/replication) covers live delivery, replica
   acknowledgements, local DBH catch-up, ring pressure, and rsync replacement.
4. [Backup and recovery history](/docs/backup-and-recovery-history) follows DBH
   from a sealed local file through object storage, controller acceptance,
   retention, and restore planning.
5. [Multi-process operation](/docs/multi-process) describes local ownership,
   presence, same-boot capture-owner replacement, and terminal cleanup.
6. [Standard, Permissive, and Lightspeed integrity modes](/docs/lightspeed) defines
   per-connection synchronous policy and clean-close proof before local reuse.
7. [Primary authority and failover](/docs/primary-and-failover) explains direct
   health evidence, controller confirmation, candidate recovery, and token
   transfer.