cyrilgdn's PostgreSQL Terraform provider keeps managing databases after HashiCorp stepped back

Why this provider exists

The README's second paragraph is the reason the project is worth knowing about.

It replaces https://github.com/hashicorp/terraform-provider-postgresql since Hashicorp stopped hosting community providers in favor of the Terraform registry.

That is a governance change rather than a technical one, and it is the kind of change that quietly breaks people's workflows. HashiCorp hosted many providers that were not part of its commercial product, and when it stopped, those providers needed new homes. This one is the continuation of the PostgreSQL provider under a personal maintainer's name, and it is published on the Terraform registry at cyrilgdn/postgresql.

The scope is what the provider manages. This provider allows to manage with Terraform PostgreSQL objects like databases, extensions, roles, etc.

Databases, extensions and roles are the core of a PostgreSQL instance's configuration, and they are the objects whose state is easiest to lose track of, because a role created by hand in psql is invisible to Terraform and will show up as drift on the next plan. The value of the provider is that it makes those objects declarative and reviewable.

The homepage is the Terraform registry documentation page, and the usage examples live in the provider documentation rather than in the README. The primary language is Go, the licence is MPL-2.0, and the last push was on 2026-08-03 with the most recent release v1.27.0 from 2026-07-06, after v1.26.0 in September 2025 and v1.25.0 in December 2024.

Building the provider

The build instructions in the README are old-fashioned in an instructive way, and comparing them with the Makefile is instructive.

The README asks you to clone the repository to $GOPATH/src/github.com/cyrilgdn/terraform-provider-postgresql, which is the pre-modules layout:

$ mkdir -p $GOPATH/src/github.com/cyrilgdn; cd $GOPATH/src/github.com/cyrilgdn
$ git clone [email protected]:cyrilgdn/terraform-provider-postgresql

Then you enter the provider directory and build:

$ cd $GOPATH/src/github.com/cyrilgdn/terraform-provider-postgresql
$ make build

The Makefile shows what make build actually does now. It depends on fmtcheck, which runs the script at scripts/gofmtcheck.sh, and then runs go install. The README says the build puts the provider binary in the $GOPATH/bin directory, and the developing section shows the result being run directly:

$ $GOPATH/bin/terraform-provider-postgresql

The README also states the requirements as Terraform 0.12.x and Go 1.16 to build the provider plugin, and in the development section says Go version 1.11+ is required.

Those numbers do not match the repository. The go.mod file declares go 1.26.0 with a toolchain directive of go1.26.2, and there is a .go-version file at the root, which is the asdf-style version pin. So the README's stated Go requirement is several major versions behind what the code actually needs, and anyone who trusts it will fail to build.

That is a documentation lag rather than a design problem, and it is worth checking go.mod directly before you start.

Acceptance tests and the local PostgreSQL container

The test story is the part of the README that is most practically useful, because the acceptance tests need a real database.

There are three levels. The unit tests are make test, which runs go test over the packages listed by go list. The full acceptance suite is make testacc, and the README warns that acceptance tests create real resources, and often cost money to run.

That warning is not boilerplate. Terraform acceptance tests provision the resources they describe and then destroy them, so against a cloud managed instance the run creates a database and pays for the instance it lives on. Against a local container there is no such cost, and the README gives the manual route for running a single test locally:

# spins up a local docker postgres container
make testacc_setup 

# Load the needed environment variables for the tests
source tests/switch_superuser.sh

# Run the test(s) that you're working on as often as you want
TF_LOG=INFO go test -v ./postgresql -run ^TestAccPostgresqlRole_Basic$

# cleans the env and tears down the postgres container
make testacc_cleanup 

The four steps are a complete local loop. The setup target runs tests/testacc_setup.sh, the shell script sources tests/switch_superuser.sh to load the environment variables the tests need, the go test invocation is filtered to a single named test with the -run regular expression, and the cleanup target runs tests/testacc_cleanup.sh to tear the container down.

Two details are worth noting. The switch_superuser.sh step exists because the tests need to connect as a superuser rather than with the restricted credentials a normal role would have, and the TF_LOG=INFO prefix is how you see the provider's own logging, which is the difference between a test that fails silently and one that shows you the query it ran.

The ability to run one test repeatedly without paying for a cloud instance is what makes contribution to the provider practical, and it is why the Makefile has separate setup and cleanup targets rather than a single all-in-one script.

What is in the dependency tree, and what it implies

The go.mod file is more revealing about the provider's scope than the README is.

The foundation is the Terraform Plugin SDK v2 at v2.40.1, with hashicorp/go-cty v1.5.0 for the value types and lib/pq v1.12.3 as the PostgreSQL driver. There is also sean-/postgresql-acl, which is the package that handles PostgreSQL role privileges, and stretchr/testify for assertions.

Then there is the cloud layer, and it is substantial. The AWS SDK for Go v2 appears in several forms, including the RDS auth feature and STS. The Azure SDK for Go appears with azcore and azidentity. The Google side is google.golang.org/api at v0.280.0 and, notably, gocloud.dev at v0.45.0, which is the Go CDK for managing multiple clouds through one interface.

The gocloud.dev dependency explains the pattern. The provider can create a database on a managed service rather than on a PostgreSQL instance you already have, and it can do that across AWS, Azure and Google through a single abstraction, with the cloudsql-proxy appearing as an indirect dependency. The STS dependency in the AWS set is for generating the temporary credentials that a managed instance needs.

blang/semver v3.5.1 is there for version comparison, and golang.org/x/net and golang.org/x/oauth2 are the network and authentication primitives the SDKs need.

That dependency set is the trade-off in this provider. It manages plain PostgreSQL objects and managed cloud databases in the same tool, which is convenient, and it also means the binary carries the AWS, Azure and Google SDKs whether you use them or not. The Go module path is still github.com/terraform-providers/terraform-provider-postgresql, the original HashiCorp-era path, which tells you this is a continuation of that codebase rather than a fresh implementation under the new name.

Where this provider fits, and where it stops

The comparison worth making is with the HashiCorp provider it replaces and with writing the SQL yourself.

Against the HashiCorp provider, the difference is continuity of maintenance rather than of design. If you had configurations written against hashicorp/postgresql, this provider is the one that keeps getting them working, because it is the same codebase under a new maintainer. The resource syntax does not change under you, which is the single most important property for a provider people have hundreds of lines of configuration for.

Against writing the SQL by hand, the difference is state. Terraform knows what it created, so a role that exists in the database but not in the configuration shows up as drift, and the change is reviewed like any other. A migration script does not know what the last script did, so the two drift apart and eventually conflict.

The limits are worth naming. The provider manages PostgreSQL objects, not the server itself, so provisioning an instance, its storage and its backups is a separate concern that the cloud database support partly covers but does not replace. The README does not describe a compatibility matrix for PostgreSQL versions, so you have to check what your server version does. And the acceptance test warning is real: the full suite provisions real resources, and against a managed instance that means real cost.

The documentation lag is the thing to plan around. The README's stated Terraform 0.12.x and Go 1.16 requirements are historical, the go.mod demands Go 1.26.0, and the GOPATH-based clone instructions predate modules. None of that blocks use of the released provider from the registry, since you do not build it to consume it, but it does mean the README is a description of the project as it was rather than as it is.

The repository structure is otherwise conventional for a Terraform provider. The website/ directory holds the documentation sources, examples/ contains usage examples including an rds/ directory and an issues/ directory, the postgresql/ directory holds the provider implementation, scripts/ holds the gfmtcheck.sh script, tests/ holds the acceptance test scripts, and .golangci.yml and .goreleaser.yml cover linting and release automation.

The MPL-2.0 licence is worth understanding for a provider, because it is a file-level copyleft licence: modifications to the provider's own files must be published under the same terms, while the provider as consumed by your configuration imposes nothing on your code.

Editorial conclusion

cyrilgdn's PostgreSQL provider suits a team that was already using the community provider and wants to keep managing databases, extensions and roles through Terraform without changing the resource syntax, since it is a continuation rather than a rewrite. It is the wrong tool if your infrastructure lives entirely in one cloud, because the managed database support is a second path through the same provider and adds several cloud SDKs to the dependency tree, and it is the wrong tool if you need a stable release cadence you can plan upgrades around. Before upgrading, read the CHANGELOG.md, and note that the README's stated Go requirement of 1.16 is well behind the go.mod directive, so check what your toolchain actually needs.

Frequently asked questions

Official sources

1. cyrilgdn/terraform-provider-postgresql on GitHub
2. License: MPL-2.0
3. Project website
4. README
5. Releases