Running twelve database engines through one lifecycle

Creating a database makes a good demo. Restoring it after a failed change tells you much more about the platform.

For a team running several engines, the difficulty is keeping the routine work understandable. Someone needs to know how to increase capacity, apply an upgrade, check a backup, and recover data, including when the person who set it up is unavailable.

Give operators a consistent place to start

A shared lifecycle interface reduces the number of tools an operator has to learn. Create, resize, restart, upgrade, back up, and restore should be recognizable actions, with clear progress and failure states.

Consistency also means showing what an action will affect. Before a restore starts, the operator needs to know whether it replaces data in the existing instance or creates another instance. A familiar button is only helpful if its consequences are visible.

Keep the engine’s rules visible

PostgreSQL and a search engine do not recover in the same way. Backup formats, consistency requirements, storage behaviour, and supported upgrade paths belong to the engine underneath the interface.

In Nothi, the PostgreSQL recovery path creates a new instance. Other supported paths restore in place. Those are materially different operations: the first needs capacity for another instance; the second can overwrite data. They should never be presented as interchangeable.

The same caution applies to tiers. A shared database cannot simply expose a cluster-wide backup to one tenant, because that backup may contain other tenants’ data. Availability of an operation needs to follow the engine and tenancy model.

A controller still needs a useful failure state

Reconciliation lets a platform keep working toward a requested state after the initial request. That helps when an operation spans several steps or a worker restarts.

It does not make every operation safe to retry blindly. An unavailable object store, insufficient capacity, or an unsupported version needs a visible explanation. The operator should be able to tell whether to wait, fix a dependency, or stop and investigate.

Test the recovery path you expect to use

A recent backup is useful evidence that a job ran. A restore exercise answers a different question: can this backup recover the data you need?

Test with representative data, check the recovered application’s behaviour, and record the time required. Repeat when the engine version, backup mechanism, or storage changes. A previously validated path can become stale.

What Nothi brings together

Nothi provides a common lifecycle surface across twelve enabled engines, backed by engine-specific adapters and backup providers. The documented enabled-engine set has validated backup and restore paths, with operation support depending on the engine and tier.

That does not mean every engine behaves identically, or that every backup is automatically restored as a test. Nothi’s routine backup freshness check checks recorded backup coverage; it is separate from a restore rehearsal.

For a useful evaluation, pick the engine you rely on most and walk through an upgrade failure and a recovery. Pay particular attention to what the platform tells the person responsible for the next step.