Terraform 0.14.5 connects to PostgreSQL with SCRAM authentication
A PostgreSQL driver update removes an authentication constraint from Terraform's state backend. The backend's database design explains why that small change matters.
A database authentication policy can stop an infrastructure operation before Terraform evaluates a resource. The PostgreSQL state backend must first connect to the database that holds its state. If that connection cannot authenticate, changing a provider configuration cannot resolve the failure. Terraform 0.14.5, released on January 20, adds support for the scram-sha-256 authentication method in that backend.
The implementation is smaller than the operational consequence suggests. Rémi Lapeyre's pull request 26886 updates the Go PostgreSQL driver, github.com/lib/pq, from v1.0.0 to v1.8.0. Its description identifies SCRAM support as the reason. Terraform does not add a new authentication expression to HCL. Updating the executable gives the existing backend a client library that understands the server's authentication method.
I value Terraform's ability to put a reusable configuration language over infrastructure APIs. This change is a useful reminder that the abstraction also depends on ordinary database clients. A backend can be conceptually simple and still inherit a deployment constraint from a dependency that configuration authors never select themselves.
Authentication belongs to the backend connection
The backend documentation shipped with this release describes pg as a standard backend with locking. It stores state in PostgreSQL and requires version 9.5 or newer. Its configuration accepts a PostgreSQL connection string. The database must already exist before initialization, so the backend is not a mechanism for bootstrapping its own database.
The minimal configuration can leave the connection details out of the source file:
terraform {
backend "pg" {}
}
The documented partial-configuration mechanism supplies conn_str during terraform init. That distinction matters because the connection string typically contains credentials. The documentation specifically recommends keeping those credentials out of committed configuration. The example above establishes the backend type without pretending that credentials belong in a reusable module.
SCRAM support changes which PostgreSQL authentication configurations that connection can satisfy. It does not alter the role of the connection string, provision a database user, or grant database permissions. Those are separate concerns. An authentication method supported by both endpoints is a prerequisite for the database operations that follow.
The driver update also explains why a provider upgrade is the wrong dependency to investigate for this particular failure. The patch changes Terraform's own Go module dependency. Terraform includes the pg backend in its executable. Selecting a newer infrastructure provider does not replace that compiled database client. For this feature, the relevant software version is Terraform 0.14.5.
What the authenticated connection protects
The backend documentation describes one states table in a PostgreSQL schema. The default schema name is terraform_remote_state, and the workspace name identifies a row. Configurations that do not use multiple workspaces use the name default. The table contains the state as text, a unique workspace name, and a serial integer identifier used for locking.
That layout makes PostgreSQL more than a place to upload a file. Terraform also uses PostgreSQL advisory locks to coordinate state access. The documentation ties its minimum database version to advisory locking and the ON CONFLICT upsert syntax. Authentication therefore precedes both reading the state and establishing the database coordination that protects a state operation.
The locking behavior has a concrete administrative consequence. This backend does not support Terraform's force-unlock command. Database-native advisory locks release when the session aborts or the connection fails. PostgreSQL's pg_locks view is the documented place to inspect outstanding locks. Applying the expectations of an unrelated backend would obscure how this one recovers from a lost connection.
Database permissions can also shape initialization. The backend provides skip_schema_creation, skip_table_creation, and skip_index_creation options for installations where an administrator creates those objects in advance. SCRAM support does not remove that separation of responsibilities. A client can authenticate successfully and still lack permission to create the schema or table.
I prefer this explicit distinction between connectivity and state administration. It makes the scope of the patch understandable. The release removes a client authentication limitation while preserving the existing storage design, including its dependence on database sessions for locking.
A separate correction to numeric presentation
The same release repairs long-number formatting in outputs and the interactive console. Pull request 27479 shows the exact change. The renderer already obtains the number through AsBigFloat(). The patch changes the formatting mode passed to Text from g to f, retaining the precision argument of -1.
This is a presentation correction, not evidence of a change to Terraform's number type. The new tests expect 1234567890 to render as that decimal integer. They also cover a large value with a fractional component, 123456789.01. Those tests are more informative than a general statement that the release improves numeric accuracy. They establish which textual representations the renderer must produce.
That distinction matters when a human reads an output to compare it with a value elsewhere. An exponent-form representation and a fixed decimal representation can describe the same quantity while creating different work for the reader. The patch addresses the display contract at the point where Terraform converts its value into text.
The database change and the formatting correction have different mechanisms, but both concern interfaces outside the resource graph. One connects Terraform to its state database. The other presents evaluated values to a person. For PostgreSQL-backed configurations, 0.14.5 expands the authentication methods available without changing the schema or the documented locking behavior.