# SQLStyle > SQLStyle runs SQLite in the application process, replicates directly from primary to replicas, uses a hosted controller to assign primary authority, and recovers from customer-owned S3-compatible storage. SQLStyle accounts, hosted coordination, and billing are available through sqlstyle.com. Reads stay local. SQLStyle selects one writer, keeps other nodes read-only, and rejects stale-writer recovery reports. ## Preferred context - [Complete documentation corpus](https://sqlstyle.com/llms-full.txt): All public docs in one plain-text response - [Documentation manifest](https://sqlstyle.com/docs-manifest.json): Structured metadata and HTML/Markdown URLs - [Human documentation index](https://sqlstyle.com/docs): Rendered documentation ## Start - [Getting started](https://sqlstyle.com/docs/getting-started.md): Create an account and open a local SQLite database with replication, writer coordination, and recovery managed around it. ## Architecture - [Architecture overview](https://sqlstyle.com/docs/architecture.md): SQLStyle runs with the Bedrock SQLite/WAL2 database core in each application node. Bedrock publishes committed WAL2 pages into a bounded capture ring, whose records feed direct replication and DBH recovery history. A hosted controller assigns primary authority and fences accepted recovery progress without carrying queries, replication traffic, or backup objects. - [Database core and capture](https://sqlstyle.com/docs/database-cores-and-capture.md): The Bedrock build adapts patched SQLite and WAL2 to SQLStyle's transaction model. Commits publish a requested WAL2 frontier without compression or network work. Capture retains the required WAL2 bytes, encodes pages as predecessor-based differences or complete LZ4 pages, and publishes recoverable records to the shared ring before advancing capture completion. - [Replication and catch-up](https://sqlstyle.com/docs/replication.md): The current primary sends captured physical transactions directly to each replica. A replica acknowledges only after committing locally, while the primary does not wait for that acknowledgement. Sessions resume from the capture ring, then local DBH, and perform one exact rsync replacement when neither source covers the requested transaction. - [Backup and recovery history](https://sqlstyle.com/docs/backup-and-recovery-history.md): DBH workers turn the capture ring into append-only local history. Finalized segments are validated and cataloged before asynchronous upload; failures remain retryable without stopping capture. Full snapshots provide recovery bases, while the controller fences the contiguous uploaded frontier that readers may treat as authoritative. - [Multi-process operation](https://sqlstyle.com/docs/multi-process.md): Every process opens SQLite directly, while a per-database shared memory coordinates one capture host and independent presence leases. The operating system releases capture ownership when its process exits. A same-boot successor validates the shared ring, WAL frontiers, DBH prefix, and controller grant before resuming; a companion can finish recovery when no application process remains. - [Standard, Permissive, and Lightspeed integrity modes](https://sqlstyle.com/docs/lightspeed.md): Standard starts managed user connections at synchronous=NORMAL, restricts later values to NORMAL or FULL, and applies live replication at NORMAL. Permissive preserves the database core's user-connection default, permits every supported synchronous value, and applies live replication at NORMAL. Lightspeed starts user connections and applies live replication at OFF, then requires authoritative recovery when an enrolled local image lacks the required clean-close SHA-256 proof. Each node selects its own mode, and attached processes follow the active owner's coherent policy. - [Primary authority and failover](https://sqlstyle.com/docs/primary-and-failover.md): Capture owners detect broken holder connections through direct health streams, while the controller alone can end an authority grant. Fast failover uses the live holder and connected vote-capable connections. A promotable runtime must cover the required recovery transaction before receiving a newer fencing token. ## Concepts - [Application Stored Procedures](https://sqlstyle.com/docs/application-stored-procedures.md): An Application Stored Procedure is a named, typed database operation whose handler is application code and whose execution follows the database primary. Defining one with the Go SDK returns a typed function; defining one with the Rust SDK returns a typed Procedure. Invoking the function or calling Procedure.call runs the handler directly when local or routes the invocation to the primary. If no writable primary is ready, the SDK waits up to the configured primary wait timeout, eight seconds by default, before returning primary-unavailable. IASP gives SQLStyle ownership of the transaction and idempotent remote execution; ASP leaves transaction and duplicate handling to the application. - [Node capabilities](https://sqlstyle.com/docs/node-roles.md): SQLStyle has no node roles; five independent capabilities describe what each connection may do. ## Guides - [Object storage](https://sqlstyle.com/docs/object-storage.md): SQLStyle stores backups in your S3-compatible bucket, keeps the secret local, and preserves a verified recovery path during retention. - [Point-in-time recovery](https://sqlstyle.com/docs/restore-and-recovery.md): Embedded SQLStyle writes snapshots and incremental history to customer-owned object storage; database recovery commands verify the accepted chain and restore the latest state or a selected point in time without requiring a surviving node. ## Reference - [Status and SQL surfaces](https://sqlstyle.com/docs/status-and-sql-surfaces.md): SQLStyle exposes operational state as SQLite tables and functions; applications should use sqlstyle_status and write only while authority is held. - [What consumes controller-state writes](https://sqlstyle.com/docs/controller-state-writes.md): Creating a database normally consumes four controller-state writes. Creating or revoking a database-scoped key consumes one write per affected controller, while deleting a database removes its controllers without adding writes. Analytics collections use the database controller, and changing database TLS consumes one write per active controller. Authority assignment, release, reconnect, and failover also consume writes when authority state changes. Restore commands, analytics exports, and promotable runtime startup consume one only when their fenced read advances the accepted recovery frontier. SQL transactions, replication, backup uploads, and ordinary heartbeats do not count. - [CLI reference](https://sqlstyle.com/docs/cli-reference.md): Use the SQLStyle CLI for databases and recovery; use the web dashboard for accounts and billing.