Most GUCs in this series will be operationally irrelevant to most readers. This one is not. application_name is the single cheapest piece of observability infrastructure PostgreSQL ships, and an astonishing number of production databases are running with it unset or stuck at a client library’s default (psql, PostgreSQL JDBC Driver, or — my favorite — the empty string).

It is a per-session label. Default is empty, context is user, so any role can set it. Set it via SET application_name = 'order-service';, via the application_name connection parameter, or via the PGAPPNAME environment variable, which libpq honors automatically. Maximum length is NAMEDATALEN - 1 — 63 bytes in a standard build — and non-printable characters are replaced with ?.

Why you should care

  • pg_stat_activity exposes it as a column. When you run the “what’s running right now” query at 2am, application_name is how you tell “the cron job” from “the user-facing API” from “the analyst’s ad-hoc notebook.”
  • log_line_prefix has a %a placeholder. Set it, and every log line carries the label. grep becomes a debugging tool again.
  • synchronous_standby_names matches standbys by their application_name. For sync replication, the value each standby sets in its primary_conninfo is what the primary uses to decide quorum.
  • Monitoring tools (pganalyze, pgwatch, home-rolled dashboards) segment by it. Granular per-service metrics are free if the labels are good, impossible if they aren’t.

What’s already doing this (for better or worse)

The PostgreSQL command-line tools set sensible defaults via libpq’s fallback_application_name: psql identifies itself as psql, pg_dump as pg_dump, pg_basebackup as pg_basebackup, and so on down the list. If you see any of these in pg_stat_activity, you know exactly what’s running and can act accordingly. The JDBC driver sets PostgreSQL JDBC Driver — unhelpful but at least non-empty. pgAdmin sets something like pgAdmin 4 - CONN:1234567, which includes the session identifier and is genuinely useful. The pg gem (Ruby) and psycopg (Python) leave it empty unless you configure them.

The pattern: production-grade tools set identifying defaults. Application drivers leave it to you.

Setting it in the frameworks you actually use

Django

Pass application_name through OPTIONS in DATABASES:

1DATABASES = {


2    'default': {


3        'ENGINE': 'django.db.backends.postgresql',


4        'NAME': 'myapp',


5        'OPTIONS': {


6            'application_name': f'myapp-{os.environ.get("DYNO", "local")}',


7        },


8    }


9}

Everything in OPTIONS is forwarded as keyword arguments to psycopg. Include your dyno, pod, or hostname if you want per-instance granularity.

SQLAlchemy

Two equally good options. In the URL:

1create_engine("postgresql+psycopg://user:pw@host/db?application_name=myapp-worker")

Or in connect_args:

1create_engine(


2    "postgresql+psycopg://user:pw@host/db",


3    connect_args={"application_name": "myapp-worker"},


4)

Same result. Pick whichever fits your config style.

Active Record (Rails)

In config/database.yml, add application_name as a key — the ActiveRecord PostgreSQL adapter forwards unknown keys to the pg gem, which passes them through to libpq:

1production:


2  adapter: postgresql


3  database: myapp_production


4  application_name: <%= "myapp-#{ENV.fetch('HOSTNAME', 'unknown')}" %>

On Kubernetes, HOSTNAME is the pod name by default, which gives you per-pod attribution for free.

For all three: if you want one label without touching config, set PGAPPNAME in the process environment. libpq picks it up automatically, and every connection from that process inherits it.

Naming conventions that earn their keep

service-role-version — e.g. checkout-writer-v4, analytics-reader, migrations-2026-03-15. Include enough to disambiguate; skip anything high-cardinality. application_name is not where request IDs go.

Operational notes

  • pgbouncer tracks application_name per-client by default in transaction pooling mode, so the backend always sees the right one. Set application_name_add_host = 1 if you also want client IP and port appended — useful when a single service has many instances behind the same label.
  • Most client library defaults are useless. Override in the connection string. Do not trust the default.
  • The 63-byte limit is real. Truncation is silent. Leave headroom.

Recommendation: Set it everywhere. Set it well. The five minutes you spend updating connection strings across your services is the first thing you’ll thank yourself for at 2am.