Databases for PostgreSQL that Is Private, Allow-Listed and Protected
service_endpoints decides whether the deployment answers on the internet and public is the default; deletion_protection defaults to false; an empty allowlist means any address that can reach the endpoint; and disk and backup encryption use IBM's keys unless yours are given. Private with public by name, deletion protection on, ranges expected (empty by name), both key CRNs taken, two members.
Verification
Static-verifiedPassed: validated and lint-clean (provider-schema-validated for AWS/Azure/GCP; Terraform-language lint elsewhere).
Conformance
- Static validation (fmt · validate · tflint)
- No applicable security policies for this provider
- Plan tests (mocked: validation rules · outputs)
Provenance
- SHA-256 checksum
- Signature (pending)
Functional
- Live test pending (no cloud run yet)
Last verified 2026-09-14 · how we verify
Use it from the registry
terraform · opentofumodule "databases_postgresql" {
source = "www.iac-bazaar.com/iac-bazaar/ibm-databases-postgresql/ibmcloud"
version = "1.0.0"
}Needs a registry token from /account/tokens. The module itself is free; the account is what identifies you. Full setup: registry docs.
Inputs & outputs
Create a free account to read this module's contract
The declared contract - every input name, type, default and description, plus every output - is shown to signed-in accounts, not to anonymous visitors.
A free account sees the contract of every module in the catalogue. There is no subscription and nothing to buy - the modules are free to download, and they run under Vizier.
Documentation
ibm-databases-postgresql
An IBM Cloud Databases for PostgreSQL deployment that is private,
encrypted with keys you hold, protected from deletion, and reachable
only from where you say. Works with Terraform and OpenTofu
(>= 1.6), IBM-Cloud/ibm provider >= 1.60, < 3.0.
The endpoint is public unless you say private. Private here; else
accept_public_endpoint.
Deletion protection on; allowlist expected (empty needs
accept_empty_allowlist).
Disk and backup keys are separate buyer knobs.
Verification
Static validation runs tofu fmt, init, validate, tflint and checkov.
This module has not yet had a live test, so it is published as statically
validated with its live test pending and does not carry the live-tested mark.
Usage code & full reference need an account
The complete copy-paste usage, the full input/output reference, and operational notes are free with an account - shown here and bundled in the download. Sign in and this section fills in.
- Usage
Related modules
ibm-cloudant
A Cloudant instance on the standard plan with CORS off, and a wildcard origin together with allow_credentials refused outright because it would let any site make authenticated requests as the signed-in user. Legacy username-and-password auth is off, and data events are on, since without them the trail never records that anyone read a document.
ibm-databases-redis
An IBM Cloud Databases for Redis deployment on the private endpoint only (public by name), with deletion protection on, an allowlist of your ranges (empty by name), disk and backup encryption with Key Protect keys you hold (IBM's keys by name), and the two-member group that is the HA and cannot be reduced. Access is by service credential, a separate resource.
ibm-db2
A Db2 deployment on a private endpoint with high availability on, disk encryption with a key you hold, and named ranges, because Db2 reads an absent allow list as any address rather than none. Autoscaling is off unless configured and its plan limit is the point: it is the difference between a slow hour and an unbounded invoice. Oracle compatibility is fixed at creation.
ibm-databases-elasticsearch
A Databases for Elasticsearch deployment on a private endpoint with deletion protection on, your Key Protect keys for both the data and the backups, and an allowlist that must name ranges because an empty one is read as any address. Three members, fixed rather than offered as a knob with one safe value. The plan, not the module, decides whether field-level security exists.
civo-database
firewall_id is optional and a database without one answers to every address that can reach its endpoint; nodes = 1 is one node whose failure is downtime; and backups are the platform's, not configurable here. Firewall and network required, two nodes (one by name), the password as a sensitive output, and an output that says no backup schedule can be set.
vultr-database
A managed database gets a public hostname and trusted_ips is optional: left empty, any address on the internet may try the password; the backup hour is picked for you; and a plan with no replicas is one node whose failure is downtime. Trusted ranges required (a /0 refused unless accepted), a VPC attachment, one standby by default, both windows set, and the password as a sensitive output.