What consumes controller-state writes

SQLStyle counts a controller-state write when an action changes coordination data held by the hosted controller. The allowance is shared by every controller in the account for the current usage period.

One action can consume more than one write. Database creation performs several controller updates, and account-level changes can apply to more than one controller. SQL transactions and replication traffic do not consume the allowance.

Database and account actions

Action	Controller-state writes
Create a database	Normally 4 writes to provision its controller.
Retry failed database provisioning	Successful controller updates performed by the retry count again. The total depends on where the earlier attempt failed.
Enable an analytics collection	No additional controller-state writes; analytics uses the application database.
Create a database-scoped key	1 write for the database controller.
Revoke a database-scoped key	1 write for each controller from which the key is removed. Revoking an already-revoked key does not add another write.
Enable or disable database TLS	1 write for each active application or analytics controller in the account. Reapplying the current setting does not count.
Delete a database	0 writes. SQLStyle revokes its database-scoped keys in the backend, records existing usage, and deletes its controllers wholesale. Earlier usage remains counted.

Creating storage profiles, listing resources, reading status, and viewing account usage do not write controller state.

Application and recovery actions

Action	Controller-state writes
Open an application instance with promotable: true	Before requesting primary authority, the instance checks the authoritative recovery frontier. That check consumes 1 write only when it publishes newer uploaded progress. Assigning the instance as the first primary consumes 1 more.
Release or transfer primary authority	A completed release or direct handoff consumes 1 write.
Restart the current primary	If the controller records the disconnect and later resumes the same primary, each persisted authority transition consumes a write.
Run sqlstyle database NAME restore or a recovery command	The command consumes 1 write only when its fenced read advances the accepted recovery frontier.
Run sqlstyle analytics export or view with a database source	The export consumes 1 write only when its fenced read advances the analytics database’s accepted recovery frontier.

The object-storage read fence used by these actions is conditional. If no primary is live, or the primary’s uploaded frontier is not newer than the value already held by the controller, the controller returns the existing value without a write.

Automatic failover

Failover can consume several writes without a dashboard or CLI action. The controller can write when it places the current primary in recovery, reserves a replacement, and completes the replacement’s promotion. Heartbeats and health reports do not count on their own; the authority changes they cause do.

What remains unmetered

These operations do not consume controller-state writes:

• SQLite reads, writes, transactions, checkpoints, and Application Stored Procedure calls
• capture, replication, acknowledgements, DBH catch-up, and rsync replacement
• DBH generation, snapshots, and object-storage uploads
• established controller connections, topology messages, heartbeats, and health reports that do not change primary authority
• controller status, usage collection, and usage enforcement

For example, a new database normally uses 4 writes during provisioning, creating its first runtime key adds 1, and assigning the first application instance as primary adds 1. Normal SQL and replication traffic after that does not move the counter.