Operations

This guide turns the current engine contract into repeatable deployment, observation, backup, upgrade, and incident procedures. It assumes NYXDB is reachable only on a controlled closed network.

The supported runtime is one all-in-one nyxdb process with local persistence. Replication, automatic failover, distributed query execution, rolling upgrades, and multi-statement transactions are not current production capabilities.

Start here

Supported boundaries

Know which engine contracts are implemented, experimental, or absent.

Production checklist

Day-zero, launch, steady-state, and recovery gates.

Deployment

Pin a revision, persist the data directory, and stop cleanly.

Configuration

Build a reviewed command line from executable defaults.

Operator governance

Secure operator access, separate grant domains, audit enforcement, and roll out application endpoints.

Health and readiness

Separate static image preflight from live engine probes.

Durability

Choose an acknowledgement and crash-loss contract.

Protect and maintain

Storage

Policies, parts, flush, compaction, and local topology.

Backup and recovery

Create, verify, retain, restore, and drill native backups.

Upgrade compatibility

Plan an offline upgrade and evidence-based rollback.

Memory governor

Set the memory envelope and understand ramp/block behavior.

Query admission

Bound concurrency, queueing, time, output, and operator memory.

Observe and respond

System tables

Live and retained local telemetry surfaces.

Metrics and events

Build alerts from gauges, counters, queries, and subscriptions.

Profiling

Escalate from SQL telemetry to Tracy or Linux eBPF.

Troubleshooting

Symptom-led diagnosis with safe recovery actions.

Every change should leave three artifacts: the exact image or binary revision, the reviewed startup command, and evidence from a recent restore drill.