---
title: "What consumes controller-state writes"
description: "See which database, account, and runtime actions consume the controller-state write allowance."
section: "Reference"
source_url: "https://sqlstyle.com/docs/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](/docs/backup-and-recovery-history#the-controller-fences-authoritative-storage-progress)
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.