Database

The database is one of the main performance and upgrade boundaries for a self-hosted Allure TestOps installation. Use this page when you are planning a production deployment, tuning PostgreSQL for sustained automated-result load, or checking whether your current database posture matches the requirements of the current server release line.

When this guidance matters

This page is most relevant when:

• you are building a production or long-lived self-hosted installation;
• you expect continuous automated result upload and analytics load;
• you are upgrading to current 5.x releases and need to confirm the supported PostgreSQL baseline.

For demos or short evaluations, simpler database placement may work. For production, treat the database as a dedicated platform dependency rather than as an in-cluster convenience service.

Database requirements

Production deployment model

For production, deploy PostgreSQL outside the TestOps application runtime. A database running in the same pod, PVC, or container stack is acceptable for proof-of-concept work, but it may become a bottleneck under sustained upload and analytics load.

Storage hardware

Use SSD-backed storage for the PostgreSQL data directory. HDD-backed storage causes progressively worse query latency as the dataset grows and is not an appropriate long-term choice for production Allure TestOps workloads.

PostgreSQL version baseline

Current Allure TestOps server installation and upgrade guidance requires PostgreSQL 15 or newer. When using version below 15 Allure TestOps will fail to start.

• Minimum supported version: PostgreSQL 15.
• Recommended versions: PostgreSQL 15 and 16.

PostgreSQL parameters

Tune these settings according to your storage profile and the number of TestOps service instances that connect to the database.

random_page_cost

This parameter strongly affects query planning for storage-backed reads.

• For SSD-backed storage, start around 1.5.
• For very fast SSD-backed storage, teams often tune it lower, for example around 1.2.
• Avoid the default 4.0 on SSD-backed production storage.

work_mem

work_mem depends on available database RAM and the total number of active application connections.

Changing work_mem requires a database restart.

Use this planning formula:

work_mem = (db_available_ram * 0.2) / (num_of_testops_service_instances * connection_pool_size_per_instance)

Where:

• db_available_ram is the RAM available to PostgreSQL;
• num_of_testops_service_instances is the number of TestOps service instances;
• connection_pool_size_per_instance is the connection pool size per instance of the main data source.

Example:

• available database RAM: 64 GB;
• TestOps service instances: 10;
• connection pool size per instance: 10.

Then:

work_mem = 64000 * 0.2 / 100 = 128 MB

effective_io_concurrency

Use a higher value for SSD-backed storage than for HDD-backed storage.

• SSD-backed storage: start around 64.
• HDD-backed storage: keep the low default-style setting.

shared_buffers

Start with at least 50% of the RAM available to PostgreSQL. On dedicated database hosts with headroom, teams often tune it higher, but only after observing the actual memory pressure on the host.

Managed services

If you use a managed PostgreSQL service such as AWS RDS, make sure the storage profile and IOPS limits are appropriate for sustained TestOps write load and analytics queries. Avoid storage plans that cap IOPS below the operational needs of the instance.

Managed PostgreSQL platforms often apply parameter changes through parameter groups and maintenance or restart windows. Plan changes to values such as work_mem and shared_buffers as database operations, not as instant application toggles.

Creating the database

Allure TestOps uses a single PostgreSQL database for user-management data and test-related data.

1. Connect to PostgreSQL with an administrative account.
2. Create the database user.
3. Create the database.
4. Grant the required privileges to the database user.
5. Grant schema privileges inside the database.

Example:

-- create a new database user
CREATE USER testops with encrypted password 'PaSSw0rd';
-- create the database
CREATE DATABASE testops TEMPLATE template0 ENCODING 'utf8' LC_COLLATE = 'en_US.UTF-8' LC_CTYPE = 'en_US.UTF-8';
-- grant all privileges to the user testops on the testops database
GRANT ALL PRIVILEGES ON database testops to testops;
-- connect to the database `testops`
\c testops
-- grant all privileges on the public schema
GRANT ALL PRIVILEGES ON SCHEMA public TO testops;
\q

Use your own database name, user, and password values instead of the example ones above.

Upgrade boundary

If you upgrade an instance from a release earlier than 25.2.1 to 25.2.1 or newer, TestOps creates additional indexes on large tables the first time the updated application starts. That work can be resource-intensive and can make the instance temporarily unavailable while the index creation runs.

If you need to reduce upgrade-time interruption, review the archived 25.2.1 index-preparation guidance before the upgrade window.

Database schema

By default, TestOps uses the PostgreSQL public schema. Change this only when your organization requires a non-default schema, and do it before the first deployment.

The chosen schema should stay stable for the lifetime of the installation.

Use an alternate schema

Treat the schema choice as a deployment-time decision. Changing the schema after TestOps has already created objects is migration work, not a harmless runtime toggle.

1. Create the target schema before deploying TestOps.
2. Make the TestOps database user the owner or grant that user full privileges on the schema.
3. Set the TestOps database-schema configuration value before the first start.

env:
  open:
    ALLURE_DB_SCHEMA: default

Separating connection pools

This tuning path is relevant only for Kubernetes deployments.

By default, TestOps uses one connection pool for all database activity. In high-load environments, you can separate connection pools so long-running operations do not starve the faster read or upload paths.

Uploader pool

Use a separate uploader pool when result-ingestion traffic should not compete with other application database work.

Enable:

• datasources.uploaderDatasource.enabled=true
• datasources.uploaderDatasource.appMaxDBConnection=<value>

Analytics pool

Use a separate analytics pool when aggregated or read-heavy queries should be isolated from the main datasource. Some teams point this pool at a read replica or a dedicated analytics-oriented PostgreSQL target.

Enable:

• datasources.analyticsDatasource.enabled=true
• datasources.analyticsDatasource.appMaxDBConnection=<value>
• the matching datasources.analyticsDatasource.* connection settings

Related pages

• Install Allure TestOps for deployment-path selection.
• Architecture and planning for the broader self-hosted topology.
• S3-compatible storage for artifact storage planning.
• Upgrade to 5.x for current major-upgrade requirements.