Database configuration
[database]
[database]
# connection = "postgres://andromeda:andromeda@localhost:5432/andromeda"
platform_max_connections = 32
write_reserve_percent = 25
acquire_timeout = "5s"
synchronous_commit = "on"
The PostgreSQL server and the default tenant's database, as a connection URL or as a table of its parts. It has no default: set it here or in ANDROMEDA__DATABASE__CONNECTION, or each part in its own variable such as ANDROMEDA__DATABASE__CONNECTION__PASSWORD. It always names PostgreSQL itself, never a proxy: tenant creation, migrations and maintenance connect here even when database.pooler is set, and so do requests when it is not.
The most connections the platform pool opens, in each broker process. It reads and writes the tenant registry every tenant load consults, the schedule of tenants with due work and the routes of forwarded subscriptions, and always connects to database.connection, even when database.pooler is set. Tenants size their own pools with tenancy.default_tenant.max_connections and tenancy.databases.max_connections.
The percentage of each tenant pool that read requests (queries, retrievals, discovery and temporal reads) never hold, so writes always find a connection however many reads queue. Rounded down to whole connections: a pool too small to spare one keeps every connection for reads.
How long a request waits for a free database connection before it is answered 503 with Retry-After.
The PostgreSQL synchronous_commit level set on the default tenant's database and every tenant database. It is installed with ALTER DATABASE ... SET, so every session inherits it, including sessions a transaction-pooling proxy hands out. With "off", a server crash can lose writes clients were already told succeeded.
[database.pooler]
database.connection.# [database.pooler]
# connection = "postgres://andromeda:andromeda@localhost:6432/andromeda"
# max_connections_per_tenant = 2
The proxy's connection, as a URL or as a table of its parts, used by requests in place of database.connection. The proxy forwards to the same PostgreSQL, so it normally differs from database.connection only in host and port. Tenant creation, migrations and maintenance keep connecting to database.connection.
The connections each named tenant's pool opens through the proxy, in place of tenancy.databases.max_connections. Keep it small: the proxy multiplexes every tenant onto its own backends, so a tenant needs only enough for its concurrent requests, and many loaded tenants do not exhaust the host's ports.
[database.name_cache]
[database.name_cache]
loading = "eager"
max_size_per_dictionary = "16 MiB"
idle_eviction_after = "8h"
When the caches are filled: as the tenant is loaded, or as names are first resolved.
The memory each of a tenant's two name caches may hold, in each broker process. A tenant holds at most twice this, and only as much as it has resolved. When a cache is full the least valuable names are dropped; a dropped name is read back from the database the next time it is resolved, so a full cache costs reads but never refuses a write.
How long a cached name may go unused before it is dropped, or "unlimited" to drop names only when a cache is full.
[database.maintenance]
[database.maintenance]
mode = "automatic"
profile = "conservative"
repack = "reported"
max_repack_size = "4 GiB"
Whether maintenance is off, only inspects and reports, or also acts on what it finds. Acts by default, so a deployment nobody tunes still gets its wraparound and WAL retention warnings, its catch-up vacuums and its index rebuilds. An action whose right the broker's role lacks is only reported. Set "observe" where the database is maintained on its own schedule.
How often the controller inspects, and how much evidence it needs before it acts.
Whether automatic maintenance also runs the online repacks of bloated tables it decides on, or only reports them. A repack copies the table while it stays in use, so the database needs free disk of up to twice the table's size, which the broker cannot measure. Repacks are only reported by default, so their decisions can be checked against the free disk first. In observe mode repacks are reported whatever this says.
The largest table, its heap plus its TOAST, the controller repacks, or "unlimited" to repack a table of any size.