Databases

Every TinyBlox product that stores data keeps it in its own PostgreSQL database. The products never need a superuser: your database administrator creates the database and its logins once, before the product is installed.

Two logins per product

Login	Used by	May
Owner	the chart’s migration Job only, before each install and upgrade	own the database, create and change tables
Runtime	the product’s running pods	read and write rows; never create, change or drop a table

Splitting them means a running pod can never change or drop the schema, and the owner’s password is mounted only in one short-lived Job.

Neither login may be a superuser or have BYPASSRLS.

Creating them

For each product, as a database administrator:

CREATE ROLE tinyguard_owner LOGIN PASSWORD '…';
CREATE ROLE tinyguard LOGIN PASSWORD '…';
CREATE DATABASE tinyguard OWNER tinyguard_owner;

CREATE ROLE tinyvault_owner LOGIN PASSWORD '…';
CREATE ROLE tinyvault LOGIN PASSWORD '…';
CREATE DATABASE tinyvault OWNER tinyvault_owner;

CREATE ROLE tinyconductor_owner LOGIN PASSWORD '…';
CREATE ROLE tinyconductor LOGIN PASSWORD '…';
CREATE DATABASE tinyconductor OWNER tinyconductor_owner;

Some products need a little more (TinyConductor’s reporting roles, for example); its guide lists it under its database setup: TinyConductor, TinyGuard.

Then put each password in a Kubernetes Secret in the product’s namespace, and name the Secret in the chart’s postgres values:

kubectl -n tinyblox create secret generic tinyconductor-pg-owner --from-literal=password='…'
kubectl -n tinyblox create secret generic tinyconductor-pg --from-literal=password='…'

What happens at install and upgrade

1. The chart starts the product’s migration Job with the owner login. It brings the schema up to the new release and exits. Running it again changes nothing.
2. Only then do the product’s pods start or roll, with the runtime login.

TinyConductor and TinyVault always migrate this way. TinyGuard 0.3 migrates from its pods by default; switch it to the Job with postgres.migrateJob.enabled: true, postgres.autoMigrate: false and the owner login under postgres.owner (see its Kubernetes guide).

If the migration fails, the install or upgrade stops before any pod changes, and the running pods keep serving. The failed Job is kept so you can read why:

kubectl -n tinyblox logs job/tinyconductor-migrate

Backups

Back up each database with your usual PostgreSQL tooling. A database backup alone is not enough to restore a product: you also need the product’s encryption key. See Backups of the encryption keys.