PostgreSQL
PostgreSQL is the only database BareBones Ticketing supports. The installer prepares the database before the application starts. This page explains what it does and what it deliberately does not do.
You do not run this page as a separate procedure. The database assistant runs as part of the install on Windows Server or Linux Docker Compose.
The two modes
| Mode | What it means | Chosen by |
|---|---|---|
| Local (Windows) / bundled (Linux) | The package installs and manages the PostgreSQL instance. Windows
installs server 18.4-2 as a service. Linux runs the
db container from the postgres:18 image. |
Default. Install-BareBonesTicketing.cmd on Windows,
./configure-database.sh on Linux |
| External | The application connects to a PostgreSQL database you already created, on a server you already run. | Install-BareBonesTicketing.ps1 -DatabaseMode External
on Windows,
./configure-database.sh --database-mode external on
Linux |
Use local or bundled mode unless your organization has deliberately approved an external target.
In external mode the server may host unrelated databases. The BareBones Ticketing database is not a shared schema — it belongs to this product alone.
The two database identities
Setup uses two separate database logins. Keeping them apart is the point.
| Identity | Who supplies it | What it can do | Where it goes |
|---|---|---|---|
| Setup login | You, in external mode. The package generates it in local/bundled mode. | Migrate BareBones Ticketing objects; create and manage roles | Only into the setup process. Never into the running application. |
| Runtime identity | Generated by setup | Ordinary application reads and writes, plus SELECT and
INSERT on the audit table |
Into the generated runtime configuration the application reads |
The setup login needs CREATEROLE or PostgreSQL
superuser rights. It needs CREATEROLE because
setup creates the restricted runtime role. It also needs authority to
migrate BareBones Ticketing objects in the target database. If the login
has neither, setup stops rather than continuing with less authority.
The runtime identity is not a superuser, owner, role manager, schema
creator, or migration identity. It is denied UPDATE,
DELETE, and TRUNCATE on audit history, and
denied DDL, object ownership, and cascade paths.
Setup creates the runtime identity once, then preserves it across later reruns.
What setup changes
Setup changes exactly these things:
- The one target database you configured.
- Schema objects owned by BareBones Ticketing, and its migrations.
- Grants and revokes local to that target database.
- The one generated runtime identity.
PUBLICcreation rights on that database'spublicschema, which it revokes.
Setup does not read, reset, reassign, or alter any other database, role, membership, setting, grant, schema, function, table, sequence, default privilege, or row on the server. If you point external mode at a server running other applications, those applications are not touched.
Why the running application refuses to migrate
Normal application startup never applies migrations.
These startup checks run when the application is configured to run as
Production. A deployment running under any other
environment name skips them and will start without verifying the
conditions below — recording one warning in the application log, naming
the environment, when it does so. Confirm the environment before relying
on this behaviour.
Before it loads data, starts background workers, or accepts traffic, it checks:
- which database identity it is connected as;
- that the schema is at the version this build expects;
- that the required objects and ordinary access exist; and
- that it is still denied audit mutation, DDL, and cascade paths.
If any check fails, startup stops. The application does not start in a degraded state.
This is why the schema is only ever changed by the installer, running under the setup login, with you present. A running web application that could migrate itself could also rewrite its own audit history.
If startup reports a pending schema or a runtime authority failure, rerun the package's database assistant. Do not fix it by granting the runtime identity migration, DDL, ownership, or audit-write authority. That denial is the mechanism, not an obstacle.
What audit append-only means, and does not
The runtime identity cannot change audit history. A database owner, a PostgreSQL superuser, the setup login, or anyone with filesystem access to the data directory still can. The product claim is append-only audit history. It is not tamper-proof, hash-chained, or write-once storage.
Reviewing the database afterwards
After first setup, a System Administrator can open Database Connection in Admin Settings. It reports the provider and connection state. It does not show the password or the raw connection string, and it is not a PostgreSQL administration console.
Upgrades and restores
Every upgrade or restore that changes the database has to go through the package's database assistant — but on one platform you never invoke it by name.
On Windows, run the new package's installer, the same command as a first install. The assistant runs inside it. There is no separate database step.
On Linux, replace the bundle files and the image,
then run ./configure-database.sh from the new
bundle — that script is the assistant, and it ships with the
package it belongs to. The copy left over from your last upgrade is the
wrong one; replacing the bundle control files replaces it.
Either way the generated runtime database identity is preserved, so you are not re-issuing credentials on every upgrade. The full procedures are in Upgrades and restarts.
What stays yours
Database accounts, network routes to the server, transport policy, patching, coordinating schema changes with your own change process, backups, restores, and testing those restores.
If it does not work
Setup reports insufficient authority. The setup
login is missing CREATEROLE, superuser, or migration rights
on the target. Get the right login from your PostgreSQL owner. Do not
raise the runtime identity's authority instead.
The generated role name collides with an existing role. Stop. Have the PostgreSQL owner resolve the collision.
Windows setup fails. Read
C:\ProgramData\BareBonesTicketing\install\last-install-failure.json
for the failing stage, correct it, then rerun the whole installer.
Linux preflight fails. The previous web service and configuration are unchanged. Correct the cause and rerun.
A connection password or connection string was exposed. Stop the install and use your organization's credential-rotation and incident process.
Do not run ad-hoc SQL, delete migration history, or make the runtime identity an owner or superuser to get past any of these.