A database connection is an operating boundary, not just a connection string. It determines who pays for the resource, who can change the schema, how credentials are rotated, what happens when the app is copied or published, and who is responsible when the provider is unavailable.
OXVO Builder supports a customer-managed path for PostgreSQL or MySQL where the current Builder environment exposes that option. The safest way to use it is to make every responsibility explicit before entering a credential.
Start with ownership, not the URI
Connecting a database does not transfer the provider resource to OXVO. Your organization still owns the database account and remains responsible for the provider bill, capacity, backups, restores, replicas, and provider-side lifecycle. Builder manages its connection to that resource; it does not become the database operator.
A useful ownership map looks like this:
Responsibility
Operational owner
Provider account, billing, backups, recovery, and capacity
Your team and database provider
Application schema and data model
Your product or engineering team
Runtime and migration permissions
Your database administrator or platform owner
Connection test, capability detection, and app runtime wiring
OXVO Builder
Credential rotation and revocation schedule
A named owner in your organization
Write this map down before launch. It prevents a common failure mode: disconnecting an app and assuming the provider resource, data, or bill disappeared with it.
Create a role for the app, not for the administrator
Use a dedicated runtime identity with only the schemas, tables, and actions the application needs. Do not reuse an owner, root, master, or other administrative account for normal traffic.
When schema changes need broader permissions, use a separate control or migration connection where your provider and workflow support it. That separation keeps day-to-day application traffic narrow while preserving a deliberate path for migrations.
The connection also needs verified transport. Builder requires certificate-chain and hostname verification rather than a skip-verification mode. Use the original provider hostname and the current public CA bundle when the provider certificate is not already trusted.
The documented connection path expects a supported public DNS endpoint. Do not infer private-network support from the presence of a provider preset, and do not weaken a provider firewall merely to make a test succeed.
Treat test and confirm as two different gates
In the app’s Cloud panel, the customer-managed flow lets you choose a provider and engine, enter runtime details, optionally add a control connection, and run Test connection. Review the detected engine, TLS result, permission checks, connection mode, and available capability snapshot before confirming.
The test is a candidate, not an immediate replacement for an active connection. A failed or abandoned candidate does not replace the currently active connection. That makes the review step meaningful: you can reject a candidate that connects with the wrong role, wrong database, or incomplete capabilities without deliberately moving the app onto it.
Confirm promptly after a successful test, then verify the app’s real server-side operations. A green connectivity check proves that Builder reached the database with the supplied role; it does not prove that every application query, migration, or concurrency pattern is correct.
Keep provider-native products separate
A database URI connects the database engine. It does not automatically connect a provider’s authentication, object storage, realtime, edge-function, backup, or administration products.
That distinction matters when a Builder app is copied, imported, or published. The app may have a valid database relationship while still needing separate authentication, storage, or provider-native setup. Document each dependency instead of treating the provider brand as one bundled capability.
Builder’s capability snapshot should guide what appears in the Cloud panel. If a database surface or operation is absent, do not simulate it in the frontend or assume that the provider name grants it.
Publish with the backend relationship in mind
A healthy Preview is not enough. When the app uses a customer-managed database, verify the published frontend and the server-side operations that depend on the active connection.
A static publication does not receive the saved database password. Database-backed behavior depends on the controlled server runtime and the active credential revision. Test the primary read and write paths, authentication or authorization boundaries that your app owns, error handling, and a clean browser session against the published revision.
Keep provider monitoring in the provider console. Connection counts, storage, backups, restore readiness, slow queries, and provider cost remain part of your operating model even when Builder shows connection health and bounded database tools.
Rotate before you revoke
Credential rotation should preserve a known-good path until the replacement proves itself:
Create or rotate the provider credential.
In Builder, choose Replace credentials.
Enter the replacement runtime and optional control details.
Test and replace.
Confirm the app is running on the new connection revision.
Revoke the old provider credential.
Builder verifies the candidate before switching the active encrypted reference. If the candidate fails, the existing active reference is preserved. This ordering reduces the chance that a routine rotation becomes an avoidable outage.
Rotate after ownership changes, suspected exposure, or provider maintenance that changes credentials or certificates. Keep the rotation owner and recovery path outside any one person’s account.
Disconnect means remove OXVO access
Disconnecting stops Builder’s runtime relationship and removes the OXVO-held connection credentials. It does not drop provider tables, delete the database, cancel the provider plan, remove backups, or stop the provider bill.
Before disconnecting, record the app that depends on the database, export anything that must be retained, identify replacement behavior, and confirm who will manage or delete the provider resource afterward.
A practical first-connection checklist
Before production use, confirm:
the customer-managed database option is available in the current Builder environment;
the intended database and provider account have named owners;
backups and restore procedures are configured at the provider;
runtime and administration use different least-privilege identities;
the supported endpoint, hostname, certificate, and connection mode are correct;
the candidate passes Builder’s engine, TLS, permission, and capability checks;
the published app completes its real database-backed journey;
rotation, monitoring, and disconnect responsibilities are documented.
The connection is ready when the app works and the ownership model still makes sense during failure, rotation, and offboarding—not merely when a test button turns green.
