Standalone ships with SQLite. Web/server nodes use MySQL or MariaDB.
Both backends sit behind the same PBE storage abstraction. The database is node state and chain persistence; it is separate from any merchant application's order database.
Deployment defaults
| Deployment | Driver | Why |
|---|---|---|
| Standalone | SQLite | Self-contained local operation with no separate database server. |
| Web / server | MySQL / MariaDB | Better fit for long-running public web deployments and higher concurrency. |
Canonical node data
| Table | Purpose |
|---|---|
| chain_meta | Schema revision, chain identity, tip metadata, supply and network settings. |
| blocks | Canonical block headers, roots, rewards, fees and raw representation. |
| transactions | Confirmed transaction index and payload data. |
| accounts | Current account balance and nonce state. |
| mempool | Validated unconfirmed transactions. |
| peers | Persisted verified peer routes and status. |
| state_undo | Per-block previous account state used during reorganization. |
Optional Commerce tables
Webhook storage is initialized only when Commerce webhooks are enabled. A normal consensus/relay node does not need merchant webhook tables, management tokens or signing secrets.
Atomic chain updates
Canonical block application updates the block, undo state, transactions, account state, mempool cleanup, tip metadata and total supply inside a database transaction. A failed update is rolled back so the stored tip and account state do not partially diverge.
Backend behavior
SQLite enables foreign keys and WAL-style local operation. MySQL startup rejects blank or unchanged CHANGE_ME-style credentials. PBE 0.0.1 also validates that the expected release-era schema shape is present rather than silently accepting incompatible legacy database layouts.
To change a standalone/operator deployment to MySQL, continue to Switch to MySQL.