RTFS Database Requirements

The Repository Federation Service (RTFS) requires a dedicated PostgreSQL database for storing event queues, member state, binary tasks, file lists, and configuration data.

Enable RTFS with a Dedicated PostgreSQL Database on Artifactory Platform Chart 7.146.7 and Later

RTFS stores federation control-plane data (events, members, binary tasks, and related state) in PostgreSQL. RTFS does not use Oracle, MySQL, or Microsoft SQL Server for its datastore.

Why Use a Separate PostgreSQL for RTFS?

Before Artifactory 7.146.7, RTFS could only connect to the same database engine as Artifactory. Teams on Oracle, MySQL, or Microsoft SQL Server couldn't enable RTFS without changing the Artifactory database platform.

From 7.146.7 onward, configure rtfs.database in the Artifactory Helm chart's values.yaml or in system.yaml so RTFS uses its own PostgreSQL while Artifactory keeps your current database configuration.

Architecture

On a single JPD, Artifactory and RTFS use independent database connections:

┌──────────────────────────────────────────────┐
│ JFrog Platform Deployment (JPD)              │
│                                              │
│  Artifactory  ◄──►  Artifactory database     │
│       │          (Oracle, MySQL, MSSQL,      │
│       │           or PostgreSQL)             │
│       ▼                                      │
│  RTFS         ◄──►  Dedicated PostgreSQL     │
│                     (RTFS schema only)       │
└──────────────────────────────────────────────┘

Federation still synchronizes artifacts and metadata between JPDs as usual. Peer JPDs don't need the same Artifactory database engine. They only need reachable Artifactory endpoints and established trust.

Prerequisites

The following table lists the prerequisites for enabling RTFS with a dedicated PostgreSQL database.

Provision the RTFS PostgreSQL Database

To provision the RTFS PostgreSQL database:

• Create an empty database and owner for RTFS:

  SQL

  CREATE USER rtfs WITH PASSWORD '<RTFS_DB_PASSWORD>';
  CREATE DATABASE rtfs OWNER rtfs;
  GRANT ALL PRIVILEGES ON DATABASE rtfs TO rtfs;

  Where:

  • <RTFS_DB_PASSWORD>: The password to assign to the new rtfs database user

  For example:

  SQL

  CREATE USER rtfs WITH PASSWORD 'S3cureP@ssw0rd!';
  CREATE DATABASE rtfs OWNER rtfs;
  GRANT ALL PRIVILEGES ON DATABASE rtfs TO rtfs;

Enable RTFS on Helm with a Non-PostgreSQL Artifactory Database

The following example shows Artifactory on Oracle with RTFS on a separate PostgreSQL instance. The Artifactory database block is unchanged when you enable RTFS. Only the rtfs section is added or updated.

Artifactory on Oracle:

postgresql:
  enabled: false

database:
  allowNonPostgresql: true
  type: oracle
  driver: oracle.jdbc.OracleDriver
  url: "jdbc:oracle:thin:@<ORACLE_HOST>:1521/FREEPDB1"
  user: "artifactory"
  password: "<ARTIFACTORY_DB_PASSWORD>"

The Oracle JDBC driver isn't bundled with Artifactory. Ship ojdbc11.jar in a custom image or mount it into Tomcat's lib directory rather than downloading it on every pod start.

Enable RTFS with dedicated PostgreSQL:

rtfs:
  enabled: true
  database:
    type: postgresql
    driver: org.postgresql.Driver
    url: "jdbc:postgresql://<POSTGRES_HOST>:5432/rtfs"
    user: "rtfs"
    password: "<RTFS_DB_PASSWORD>"

Run helm upgrade with your values file, then confirm RTFS health as described in Verify RTFS Is Running.

Enable RTFS in system.yaml for Non-Helm Installations

For RPM/Debian, archive/tarball, Docker Compose, or VM deployments, edit $JFROG_HOME/artifactory/var/etc/system.yaml.

Example for Oracle-backed Artifactory with RTFS on dedicated PostgreSQL:

shared:
  database:
    allowNonPostgresql: true
    type: oracle
    driver: oracle.jdbc.OracleDriver
    url: "jdbc:oracle:thin:@<ORACLE_HOST>:1521/FREEPDB1"
    username: "artifactory"
    password: "<ARTIFACTORY_DB_PASSWORD>"

rtfs:
  enabled: true
  database:
    type: postgresql
    driver: org.postgresql.Driver
    url: "jdbc:postgresql://<POSTGRES_HOST>:5432/rtfs"
    username: "<RTFS_DB_USER>"
    password: "<RTFS_DB_PASSWORD>"

Your existing shared.database configuration doesn't change. You only add the rtfs block. Restart Artifactory so the platform picks up the change and starts RTFS.

Verify RTFS Is Running

Check the RTFS liveness endpoint (Artifactory 7.117.5+ or 7.111.12+):

curl -s -o /dev/null -w "%{http_code}\n" \
  https://<JFROG_PLATFORM_URL>/rtfs/api/v1/system/liveness

A response of 200 indicates RTFS is up and connected to PostgreSQL.

On Kubernetes, RTFS pod logs should show JDBC connectivity and Flyway migrations on first start:

kubectl -n <NAMESPACE> logs <RTFS_POD> | grep -iE "postgres|jdbc:postgres|flyway"

Existing trust and federation configurations continue to work when you enable RTFS on an already federated environment. If you run legacy in-Artifactory federation today, enable RTFS first, then migrate configuration and state. For more information, see Migrate to the Artifactory Federation Service.

After RTFS is healthy, configure federated repositories and trust between JPDs as described in Setup Prerequisites for Federated Repositories and Create a Federated Repository or Create Your First Federation.

Production Considerations for RTFS Database

• Use rtfs.database.secrets (and existingSecret for Artifactory credentials) instead of inline passwords.
• Run managed or HA PostgreSQL for RTFS with backup and recovery procedures.
• Set appropriate resource requests, limits, HPA, and PodDisruptionBudgets per the Helm chart documentation.
• Establish JPD trust through the Platform UI or supported automation rather than ad-hoc API calls where possible.

Database Requirements

RTFS has the following database requirements.

RTFS doesn't support MySQL, MariaDB, Oracle, or other databases. PostgreSQL is required for both SaaS and self-managed deployments.

Key Tables and Data Types

RTFS stores the following categories of data in its database.

Database Partitioning

RTFS automatically manages database table partitioning for event and message blob tables. Partitioning keeps query performance stable as event volume grows by distributing data across manageable segments.

How Partitioning Works

1. The PartitionMakerJob runs on a schedule (default: every 30 minutes) and evaluates whether new partitions are needed.
2. New partitions are created when the current partition's primary key count reaches a configurable threshold percentage of the partition size.
3. The SubPartitionPrimaryKeyMonitoringJob monitors sub-partition primary key counts and reports metrics.

Partitioning Properties

The following properties control partitioning behavior.

Partitioning Metrics

The following metrics track partition growth.

Sizing Recommendations

The following table provides sizing guidelines based on deployment scale.

These are rough guidelines. Actual database size depends on event volume, binary task count, event retention period, and Full Sync frequency. For thread pool and replica sizing guidance based on deployment scale, see the Scaling and Sizing Guide.

Connection Pool Configuration

The following property configures the database connection pool.

Maintenance

• Event cleanup: The EventsCleanupJob removes processed events older than rtfs.events.cleanup.retention.time.Days (default: 3 days).
• Orphan cleanup: The MaintenanceCleanupJob removes orphaned records (default: daily at 2:00 AM).
• Partition monitoring: Monitor jfrtfs_sub_partition_total_count and jfrtfs_sub_partition_pk_count metrics to track partition growth.
• Vacuuming: Standard PostgreSQL maintenance (VACUUM, ANALYZE) applies. Configure autovacuum appropriately for high-event-volume deployments.

Frequently Asked Questions

This section provides answers to frequently asked questions.

Related Topics

• Helm Deployment Configuration
• RTFS Configuration
• RTFS Scheduled Jobs Reference