Skip to content

feat: add native PostgreSQL backend and external plugin architecture#621

Open
maelanjais wants to merge 13 commits into
abtreece:mainfrom
maelanjais:main
Open

feat: add native PostgreSQL backend and external plugin architecture#621
maelanjais wants to merge 13 commits into
abtreece:mainfrom
maelanjais:main

Conversation

@maelanjais
Copy link
Copy Markdown

@maelanjais maelanjais commented May 27, 2026

Summary

This PR adds two new backend types to confd:

  • Native PostgreSQL backend (postgres) powered by pgx/v5, with real-time change notification via LISTEN/NOTIFY (eliminating polling in watch mode), support for SQL Views to map confd keys to existing business
    tables, and standard username/password authentication.

  • External plugin backend (plugin) using HashiCorp go-plugin, allowing operators to load any custom backend at runtime as a standalone binary without recompiling confd. A
    reference implementation (cmd/confd-plugin-postgres) ships as a PostgreSQL plugin example.

Changes

New packages

  • pkg/backends/postgres/ — PostgreSQL StoreClient with GetValues (prefix scan via LIKE) and WatchPrefix (dedicated LISTEN confd_update connection)
  • pkg/backends/plugin/ — go-plugin client that launches an external binary and proxies StoreClient calls over RPC
  • pkg/backends/plugin/api/ — shared RPC DTOs, BackendProvider interface, BackendRPCClient/BackendRPCServer, and ConfdBackendPlugin boilerplate
  • cmd/confd-plugin-postgres/ — reference PostgreSQL plugin binary (demonstrates the plugin SDK)

CLI additions

  • confd postgres subcommand (--node, --username, --password, --database, --table)
  • confd plugin subcommand (--plugin-path)
  • Both backends registered in pkg/backends/client.go and pkg/backends/config.go

Config file support

  • database and plugin_path fields added to TOMLConfig so both backends can be configured from confd.toml

Tests

  • Unit tests for PostgreSQL DSN/prefix-building helpers (pkg/backends/postgres/client_test.go)
  • Unit tests for the full RPC server/client layer via in-process mock (pkg/backends/plugin/api/api_test.go)

Documentation

  • PLUGIN_ARCHITECTURE.md — plugin SDK specification and implementation guide
  • PLUGIN_DEMO.md — end-to-end demo with Docker Compose
  • POSTGRES_DEMO.md — PostgreSQL setup, SQL Views, LISTEN/NOTIFY walkthrough
  • README.md updated to list the two new backends in the feature list and backend table

Test plan

  • go test ./... passes (all 26 packages)
  • make build succeeds
  • go build ./cmd/confd-plugin-postgres succeeds
  • Config precedence (CLI > env > TOML) verified via TestLoadConfigFile_ExplicitDefaultSourcesOverrideTOML
  • PostgreSQL integration test requires a running Postgres instance (see POSTGRES_DEMO.md)
  • Plugin integration test requires building confd-plugin-postgres and a running Postgres instance (see PLUGIN_DEMO.md)

- Restore configSources/shouldApplyTOML/AfterApply for proper CLI > env > TOML
  precedence resolution (was lost when postgres/plugin backends were added)
- Add applyBackendDefaults() and move per-backend node defaults out of Run()
  to match upstream pattern; add postgres to the defaults switch
- Add Database and PluginPath fields to TOMLConfig so they are configurable
  via confd.toml
- Restore TestLoadConfigFile_ExplicitDefaultSourcesOverrideTOML and
  TestApplyBackendDefaults test coverage
- Bump Go from 1.25.8 to 1.26 / toolchain go1.26.2 in go.mod
- Update Go version pins to 1.26.3 in all GitHub Actions workflows,
  Dockerfile.build, and .tool-versions
- Restore v0.41.2 section to CHANGELOG (was absent due to rebase on older base)
- Rewrite README.md to match upstream format while documenting the new
  PostgreSQL (with LISTEN/NOTIFY watch) and Plugin backends
- Promote hashicorp/go-plugin to a direct dependency in go.mod (go mod tidy)
@abtreece
Copy link
Copy Markdown
Owner

abtreece commented Jun 4, 2026

@maelanjais thanks for the contribution!

I would be ok with adding PostgreSQL as a backend, but I'm not sure how much value it would actually bring.
I am definitely interested in a plugin system, but I would want to spend some time investigating the options before committing to a solution.

Could you minimally split these two features into their own PRs so that the can be assessed independently?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants