Does this generate a full postgresql.conf with every setting?

No, it generates the handful of settings almost every deployment needs to touch: listening address, connection limits, the two most impactful memory settings (shared_buffers and work_mem), wal_level, and slow-query logging. A production postgresql.conf has hundreds of parameters; this tool focuses on the ones you'd otherwise have to look up every time.

What's the difference between the pg_hba.conf 'host' and 'local' rule types?

'local' rules match connections over a Unix-domain socket (no network involved, so no address column), while 'host' rules match TCP/IP connections and require a CIDR address like 127.0.0.1/32 or 0.0.0.0/0 to specify which client addresses the rule applies to.

Which authentication method should I pick?

scram-sha-256 is the modern, recommended password method since PostgreSQL 10 and should be your default for password-based auth. md5 remains for compatibility with older clients. peer only works for local Unix-socket connections and matches the OS user to the Postgres role. trust should be reserved for tightly controlled local development environments, since it allows connecting without any password at all.

What does wal_level control?

wal_level determines how much information PostgreSQL writes to the write-ahead log. 'minimal' is the smallest but doesn't support replication; 'replica' (the default) adds what's needed for WAL archiving and streaming replication; 'logical' adds the extra information logical decoding needs, for tools like logical replication or CDC pipelines.

PostgreSQL Config Generator - postgresql.conf & pg

Overview

Introduction

Tuning postgresql.conf usually starts with the same handful of settings, listen_addresses, max_connections, shared_buffers, work_mem, and a decision about wal_level, each buried in a config file with hundreds of commented-out defaults.

This tool generates those core settings from a form, along with a matching pg_hba.conf built from repeatable authentication rules, so you get a correctly formatted starting point without hunting through documentation for each parameter's exact name and syntax.

What Is PostgreSQL Config Generator?

A form-driven generator for the postgresql.conf settings that most deployments actually need to change: network listening, connection limits, the two memory settings with the biggest performance impact, WAL level, and slow-query logging.

It also builds a pg_hba.conf with any number of host/local authentication rules, each specifying a connection type, target database, user, address (for host rules), and authentication method.

How PostgreSQL Config Generator Works

Each form field maps directly to one postgresql.conf parameter; values are validated (ports and connection counts must be integers, memory settings and listen_addresses must be non-empty) and then emitted as commented, grouped key = value lines matching PostgreSQL's own documentation groupings.

The pg_hba.conf section renders each rule as a single line following PostgreSQL's fixed column order (TYPE DATABASE USER ADDRESS METHOD), omitting the ADDRESS column entirely for 'local' rules since Unix-socket connections have no network address.

When To Use PostgreSQL Config Generator

Use it when standing up a new PostgreSQL instance and you want a sane starting postgresql.conf instead of copying an old config file with stale comments and settings.

It's also useful when you need to quickly hand a teammate a correctly formatted pg_hba.conf snippet for a new application or replica connecting to the database.

Often used alongside MySQL Config Generator.

Features

Advantages

Produces both postgresql.conf and pg_hba.conf together, since the two files are almost always edited as a pair when provisioning access.
Enforces PostgreSQL's fixed pg_hba.conf column order and correctly omits the address column for local rules, a common source of manual formatting mistakes.
Validates that numeric settings (ports, max_connections) are actually integers before generating output.

Limitations

Only covers a curated subset of settings; it doesn't attempt to model autovacuum tuning, replication slots, or extension-specific parameters.
Doesn't calculate recommended shared_buffers/work_mem values from your server's RAM; you supply the values directly.
Doesn't validate that pg_hba.conf rules don't shadow each other (PostgreSQL evaluates rules top-to-bottom and uses the first match), so rule ordering is still your responsibility.

Examples

A local development instance with SCRAM auth

Input

listen_addresses: localhost, port: 5432, max_connections: 100, shared_buffers: 256MB, work_mem: 4MB, wal_level: replica, log_min_duration_statement: 250ms; pg_hba rule: host, all, all, 127.0.0.1/32, scram-sha-256

Output

listen_addresses = 'localhost'
port = 5432
max_connections = 100
...

# pg_hba.conf
host	all	all	127.0.0.1/32	scram-sha-256

The generator produces both files' content in one output, clearly separated by a comment header for each file.

Best Practices & Notes

Best Practices

Set shared_buffers to roughly 25% of available system RAM as a starting point, then measure and adjust rather than guessing higher.
Prefer scram-sha-256 over md5 for any new password-based pg_hba.conf rule; only keep md5 for clients that genuinely can't negotiate SCRAM.
Scope 'host' rules to the narrowest CIDR range that covers your actual clients instead of defaulting to 0.0.0.0/0.

Developer Notes

Output is plain text, not parsed or validated by an actual PostgreSQL parser; postgresql.conf lines are grouped under PostgreSQL's own documentation section headings (CONNECTIONS AND AUTHENTICATION, RESOURCE USAGE, WRITE-AHEAD LOG, ERROR REPORTING AND LOGGING) and pg_hba.conf rows are tab-separated in the fixed column order PostgreSQL's parser expects, with the ADDRESS column omitted for 'local' type rows since it doesn't apply to Unix-socket connections.

PostgreSQL Config Generator Use Cases

Bootstrapping postgresql.conf and pg_hba.conf for a new local or staging PostgreSQL instance
Documenting the exact access rules being granted to a new application or replica
Producing a starting point to hand to a DBA or paste into infrastructure-as-code

Common Mistakes

Using 'trust' authentication outside of a fully isolated local development environment, which allows any client matching the rule to connect without a password.
Forgetting that pg_hba.conf rules are evaluated in order and the first match wins, so a broad early rule can silently shadow a more specific one added later.
Setting work_mem too high globally, it's allocated per sort/hash operation and per connection, so a generous value can multiply quickly under load.

Tips

Add your most specific pg_hba.conf rules first since PostgreSQL stops at the first match.
Use the MySQL Config Generator alongside this one if your stack runs both engines and you want consistent-looking config output for both.

PostgreSQL Config Generator