SQLStyle

Security

Security starts with explicit authority.

SQLStyle separates writer coordination, replication, and customer-controlled recovery storage so each responsibility stays clear.

Current security model

One accepted writer

SQLStyle selects one writer and gives each new primary a newer fencing token. Replica, witness, and unknown roles remain read-only, and stale primaries are rejected.

Protected replication

Database changes move directly between SQLStyle nodes. The default local transport is only for trusted, access-restricted networks; deployments needing transport protection must configure TLS mode.

Verified recovery

Restore selects an accepted snapshot and history chain, then validates object size, checksums, and transaction coverage before materializing the database.

Scoped credentials

Account credentials are used for CLI administration. Database-scoped API keys authorize individual runtime and restore workflows without exposing an account-wide key to application code.

Customer-controlled storage

Non-secret storage profile metadata can be managed through SQLStyle. The object-storage secret is supplied locally to the runtime and is not uploaded to SQLStyle servers.

Fail-closed startup

The runtime rejects incompatible state and unsupported durability configurations instead of silently bypassing capture, replication, or recovery checks.

Service posture

SQLStyle does not claim a formal compliance certification or publish an uptime commitment. Use scoped credentials, keep independent recovery procedures, and choose deployment controls that match your workload.

Report a concern

Send security reports directly.

Include the affected surface, reproduction steps, and potential impact. Please avoid placing active credentials or customer data in the initial report.

security@sqlstyle.com