Managed databases

Managed databases provide Opfield-controlled PostgreSQL, Redis, and ClickHouse instances on Storage Nodes. Opfield owns the resource lifecycle and desired configuration; the Storage Node owns the running engine and its local runtime. This separation is why an offline node does not erase the instance’s recorded configuration, and why recovery should begin with node health rather than manual engine changes.

The product decision is whether your team wants Opfield to own a bounded single-node database lifecycle or only record access to a database managed elsewhere. For a managed instance, the platform owner supplies a suitable Storage Node, the database owner defines capacity, backup, and recovery requirements, and application owners consume the service through private bindings. Success means the instance is ready, data protection is proven, intended clients can connect with least privilege, and a Node or service restart has a documented recovery result.

Managed does not mean maintenance-free or automatically highly available. Opfield automates provisioning, configuration, monitoring, and lifecycle actions, while your organization remains accountable for data classification, backups, restore tests, engine upgrades, capacity planning, and business continuity. For a side-by-side comparison with external connections, see Managed and external databases at a glance. Creating a managed database requires Personal or higher.

Capability boundary

Capability	What Opfield provides today	What the operator still owns
Provisioning	A bounded PostgreSQL, Redis, or ClickHouse instance on one Storage Node	Node capacity, placement, storage durability, and approved engine version
Configuration and lifecycle	Desired configuration, pause and unpause, restart, retry of failed provisioning, resize of CPU, memory, swap, and storage (storage can only grow), Redis and ClickHouse engine settings, PostgreSQL extensions, publication, logs, monitoring, and retirement workflows	Change windows, application compatibility, independent verification, and rollback decision
Application access	Managed private bindings and optional direct TLS publication	Client behavior, least-privilege use, certificate trust, and credential rotation policy
Backups	Scheduled native database backups to a storage connection, and restore into a new managed database, on Personal and higher	Backup policy, off-host destination, retention, encryption of the destination, and regular restore tests
Point-in-time recovery	Not provided automatically	WAL, AOF, or engine-specific continuous backup architecture and tested recovery procedure
Replication and automatic failover	Not provided by the bounded single-node managed lifecycle	Replicated topology, quorum, failover, fencing, and application reconnect behavior
Engine version changes	No in-place version or engine change; the version is fixed when the instance is created	Choosing the version, and moving data to a new instance with engine-native tools when an upgrade is needed
Disaster recovery	Opfield retains resource intent but does not recreate lost application data	Independent recovery location, data copies, keys, DNS/network recovery, and declared RPO/RTO

If the service requires HA, PITR, cross-region recovery, or automatic failover, use an external database platform that provides those properties and register it in Opfield as an external connection. Do not infer database availability from the fact that its Opfield resource is healthy.

Before provisioning

You need permission to create the database and use the selected Storage Node. Confirm the engine and supported version, node availability, storage and memory requirements, backup plan, and whether external client access is actually necessary. Select capacity conservatively and leave room for engine overhead, temporary work, and recovery operations.

Keep direct publication disabled unless an external client has a documented need. Private application connectivity should use bindings. Enabling direct publication is an intentional change to the instance’s exposure and does not open a host firewall automatically.

Read the curated version catalog in the UI before provisioning. Supported versions are an operational contract: do not pin an arbitrary upstream patch version or keep an obsolete engine only because its container can still start. For production data, document the upgrade path and restore compatibility before selecting a version. Each catalog version is pinned to an image digest. The Storage Node pulls it from the Opfield mirror at ghcr.io/the-square-labs/gateway first and falls back to Docker Hub, verifying the same digest either way.

Provision and verify

1. Choose the engine, supported version, Storage Node, storage size, and memory profile.
2. Review the private-by-default network posture and any direct publication setting.
3. Create the instance and follow the provisioning operation to completion.
4. Wait for the instance to show Ready before creating an application binding or relying on Explorer, Console, or metrics.
5. Verify engine health, recent logs, storage reporting, and a permitted connection path.

The first verification should include a write appropriate to the engine and a read-back through the same identity the real client will use. For PostgreSQL, verify the intended database and schema; for Redis, verify the expected key access and persistence policy; for ClickHouse, verify the target database/table path and both query and storage behavior. Remove synthetic data after the test.

Provisioning failures commonly result from unavailable nodes, capacity limits, storage preparation, unsupported engine settings, or engine startup. Read the operation result before retrying. Repeated restarts or recreation attempts can obscure the original failure and are not a replacement for correcting storage or configuration prerequisites.

Change an existing instance

Pause and unpause control compute while retaining the database data. Expect normal health, metrics, Explorer, and Console actions to be unavailable while the instance is paused. Restart creates a brief service interruption and should be announced to dependent applications when they cannot reconnect automatically.

Resize only within the engine and storage constraints. Storage can grow but cannot shrink, and resize and settings changes are unavailable while the instance is paused. A change cannot be saved while a previous change is still being applied. Monitoring history survives a period when the database or its Node was offline. Back up before a substantial capacity change, follow the resize operation, then verify storage reporting and application behavior.

Opfield keeps the engine owner credential internal and never returns it to users. Reveal credentials and credential rotation apply to a separate direct-access user that exists while TCP publication is enabled; rotation affects direct clients that use it. Application bindings retain their own engine identities and are not affected.

For a planned change, record a before-state: engine version, storage usage, connection count, current bindings, publication state, latest successful backup, and the operation owner. After the change, compare the same signals and run a real client query. If the operation fails, preserve its Task and engine logs before retrying; repeated blind retries can replace useful evidence with secondary failures.

Publication and retirement

Direct TCP publication is opt-in and should be treated as a separate external-client contract. You can enable, disable, or change it after provisioning; Opfield recreates the database container and keeps its data, so plan a short interruption. Verify the intended client, certificate trust, credentials, and network path after enabling it. Disabling publication removes that direct path but does not delete the instance or private workload bindings.

Deletion is destructive. First remove or migrate dependent bindings—Opfield rejects deletion while bindings exist or while a backup or restore of the database is running—decide how long backups must be retained, and confirm that no external clients still require direct publication. Deleting the database disables and removes its backup policies; its backup history and the artifacts in storage are kept. Opfield then removes the managed instance and its related identity and storage state through its lifecycle. Do not manually remove engine users, internal network objects, or storage in an attempt to accelerate deletion; let the recorded operation finish so cleanup remains consistent.

Operator details: storage and direct TLS

The Storage Node must pass the same storage preflight used by the runtime. Opfield-managed databases use fixed-size preallocated ext4 images rather than an unbounded Docker volume. VM and bare-metal hosts normally provide the required loop and mount capabilities. Containerized hosts require explicit loop-device and mount support; an unsupported host is rejected instead of silently falling back to weaker storage isolation. Each managed database holds one loop device while it exists, so size the loop-device pool of an LXC Storage Node for every instance, object storage member, and concurrent backup; see Storage Node and Docker Node prerequisites. Deleting an instance releases its mount and loop device before Opfield reports the deletion, and the daemon repairs devices left behind by earlier releases on its own.

The Docker daemon, not Docker’s restart policy, starts the managed engines on a Storage Node. After a reboot it mounts each instance’s disk image first and starts the engine only then, so an engine never writes into the empty mount directory on the root filesystem. An engine that stops unexpectedly is started again with a growing delay of up to one minute; an instance you stopped stays stopped. A Storage Node starts even when one of its managed containers is missing; that database shows as not running.

Direct publication uses native TLS. Opfield issues the server certificate from its separate Database CA and keeps the private key in daemon-owned storage outside the database image. PostgreSQL and Redis expose one TLS endpoint; ClickHouse exposes HTTPS and its native TLS endpoint. Clients must trust the displayed Database CA and should follow the documented hostname or certificate-fingerprint policy rather than disabling verification.

Opfield renews the server certificate automatically, checking hourly: when two thirds of its lifetime have passed, 30 days or fewer remain, a configured service address is missing, or the certificate comes from another CA. The engine reloads the new certificate in place—PostgreSQL, Redis, and ClickHouse keep serving—and Opfield switches to it only after the instance serves it. The Database CA does not change, so clients that trust it keep working. The database’s Connection Details show a quiet TLS Certificate row with the expiry date and either “renewed automatically” or “needs attention”. A notice appears on the page only when attention is needed—renewal failed, 7 days or fewer remain, the renewed certificate is not loaded yet, renewal waits for the Node daemon, or the CA limits the lifetime—with the reason, the expiry date, and Rotate now where you may rotate it. The Dashboard also shows a warning listing every managed database and managed storage whose certificate needs attention and that you may view.

Rotate TLS certificate renews it immediately with the same in-place reload. A restart is used only when you allow it, when 7 days or fewer remain, or when the Node daemon cannot reload certificates yet. While renewal keeps failing, Opfield raises the Managed Service Certificate Renewal Failed notification event. API: GET /api/databases/managed/{id}/certificate and POST /api/databases/managed/{id}/rotate-certificate with optional allowRestart; MCP and assistant: manage_managed_database actions certificate_status and rotate_certificate.

Opfield’s own connections for Explorer, Console, monitoring, and backups reach a managed instance through the mutually authenticated Relay tunnel. For PostgreSQL with TLS, Opfield additionally verifies the server certificate against the Opfield Database CA and the identity issued to that instance. Redis and ClickHouse use plaintext inside the tunnel.

Application bindings reach the instance through the same tunnel. For PostgreSQL with TLS, a binding client that connects with the plain binding URI still works: the Storage Node’s daemon opens the TLS connection to PostgreSQL and verifies the instance’s certificate, while a client that requests TLS itself keeps end-to-end TLS. See Application database bindings.

Recovery decisions

• If the Node is offline, restore the Node and daemon connection before changing the database definition.
• If provisioning failed before the engine became ready, correct the reported storage, capacity, or version problem and use the targeted retry action.
• If the engine is ready but clients fail, separate direct-publication TLS, binding state, credentials, and application configuration before restarting anything.
• If storage is damaged or data is inconsistent, stop lifecycle experimentation and restore to a separate verified target from an engine-level backup.

Pause is not a backup and restart is not rollback. Opfield can reconcile infrastructure state, but it cannot reverse an application schema migration or reconstruct data that was never backed up.