Badger Store

The Badger store uses BadgerDB for embedded key-value persistence. It gives you durable storage without an external database process.

When to use

• Single-node deployments — embedded database with no external dependencies.
• Edge/IoT — lightweight persistence for resource-constrained environments.
• Desktop applications — local data storage without a database server.
• Testing with persistence — faster than PostgreSQL, data survives restarts.

Configuration

import "github.com/xraph/ctrlplane/store/badger"

s, err := badger.New(badger.Config{
    Path:       "./data/badger",
    InMemory:   false,
    SyncWrites: false,
})

Or use it with the app:

s, err := badger.New(badger.Config{Path: "./data"})

cp, err := app.New(
    app.WithStore(s),
)

Internals

Key prefixes

Each entity type has a dedicated prefix for efficient iteration:

inst:  — instances          depl:  — deployments
rels:  — releases           hchk:  — health checks
hrsl:  — health results     metr:  — metrics
logs:  — log entries        trac:  — traces
rsna:  — resource snapshots doma:  — domains
rout:  — routes             cert:  — certificates
secr:  — secrets            tent:  — tenants
audt:  — audit entries

Secondary indexes use additional prefixes (islg: for instance slugs, tslg: for tenant slugs).

Operations

• Insert — JSON-marshal the entity and set with the key.
• Get — Direct key lookup, JSON-unmarshal.
• List — Prefix scan with BadgerDB iterator, filter by tenant and criteria.
• Update — Overwrite the key with the new value.
• Delete — Remove the key.

Limitations

• Single process — BadgerDB holds a directory lock; only one process can open the database at a time.
• No SQL queries — filtering is done in application code during iteration.
• No multi-node — not suitable for distributed deployments.
• JSON overhead — serialization adds some latency compared to binary formats.

Comparison