If your origin stack uses PostgreSQL as its relational store, your customer can supply their own PostgreSQL instance (RDS, Cloud SQL, Aurora, self-hosted, etc.) and the compiler will emit a deployment stack that talks to it instead of provisioning a default-shipped database.Documentation Index
Fetch the complete documentation index at: https://docs.tensor9.com/llms.txt
Use this file to discover all available pages before exploring further.
What the customer provides
| Field | Purpose |
|---|---|
| Hostname | The host (or host:port if non-default) of the PostgreSQL endpoint. |
| Database name | The PostgreSQL database the appliance’s services should connect to. |
| Username | The role the appliance authenticates as. |
| Password (or IAM role / managed-identity reference) | The credential for the role. The appliance can use a static password or, where supported, an IAM-backed token. |
| CA certificate (optional) | The trust anchor for the PostgreSQL server’s TLS certificate when the customer uses a private CA. |
What changes at compile time
When customer-provided PostgreSQL is selected, the compiler:- Drops the default-shipped PostgreSQL instance from the deployment stack (no RDS instance, no managed-instance provisioning, no automated backups).
- Wires the appliance’s services to the customer’s hostname and database.
- Injects the customer’s credentials as secrets the services read at startup.
What the customer takes on
When your customer brings their own PostgreSQL, they own:- Provisioning, instance sizing, and capacity planning.
- Backup, retention, and restore. Point-in-time recovery is the customer’s PostgreSQL provider’s feature, not Tensor9’s.
- Patching and version upgrades. The customer’s PostgreSQL major version must remain compatible with your application’s requirements.
- High availability, read-replica topology, and failover.
- Connection pooling, if the appliance’s connection count exceeds what the customer’s deployment can handle directly.
- Monitoring, alerting, and incident response for the PostgreSQL instance itself.
What stays your responsibility
- All application-level database concerns: schema design, query performance, application-managed migrations, data correctness.
- Your services continue to be observable through Tensor9’s normal mechanisms (logs, metrics, traces) even though the database isn’t.
- Operations commands that operate on the appliance’s services still work normally. Operations commands cannot reach into your customer’s PostgreSQL.