Skip to main content
Customer-provided PostgreSQL: the origin stack uses PostgreSQL; the customer can plug in an AWS-managed instance (RDS or Aurora), a cloud-managed instance (Cloud SQL, AlloyDB, etc.), or a self-hosted Postgres deployment. 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.

​
What the customer provides

FieldPurpose
HostnameThe host (or host:port if non-default) of the PostgreSQL endpoint.
Database nameThe PostgreSQL database the appliance’s services should connect to.
UsernameThe 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.
The customer is responsible for creating the database, granting the appliance role the privileges it needs, and applying any schema migrations your application requires.

​
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.
Your application code does not change. The connection string changes; the SQL the application emits does not.

​
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.

​
Authentication and rotation

The username and password (or IAM role / managed-identity reference) are stored as Customer-Supplied Secrets - Tensor9 has no visibility into the underlying value. The appliance reads them at startup and on connection-pool establishment. Two rotation paths:
  • Static password: rotate the password in the customer’s secret store and restart the affected services so they reconnect with the new credential.
  • IAM-backed auth (RDS IAM, Cloud SQL IAM): the appliance assumes the customer-supplied IAM role at runtime and the underlying STS token is refreshed automatically (15-minute TTL on AWS). The customer rotates the role / policy, not the credential.

​
Where this fits

This page is one of the services covered by Customer-Provided Services. For automatic cross-cloud substitution (RDS → Cloud SQL based on form factor), see Service equivalents.