RTFS Database Requirements

RTFS stores federation control-plane data (event queues, member state, binary tasks, file lists, and configuration) in PostgreSQL. RTFS does not support Oracle, MySQL, Microsoft SQL Server, or other database engines for its own datastore.

PostgreSQL for RTFS does not always mean a separate database instance from Artifactory. Shared Artifactory PostgreSQL is a supported path on versions before 7.146.7, and remains supported on 7.146.7 and later when Artifactory already uses PostgreSQL.

Shared Versus Separate PostgreSQL

The following table describes when RTFS can share Artifactory's PostgreSQL and when a separate PostgreSQL is required.

Enable RTFS with a Separate PostgreSQL Database on Artifactory 7.146.7 and Later

Starting with Artifactory 7.146.7, you can run RTFS against a separate PostgreSQL instance while Artifactory continues to use its existing database, for example Oracle. You don't need to migrate your Artifactory installation to PostgreSQL to adopt RTFS.

Why Use a Separate PostgreSQL for RTFS?

Before Artifactory 7.146.7, RTFS could only use Artifactory's PostgreSQL. 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. On Helm, leave rtfs.database.type unset to keep sharing Artifactory's PostgreSQL. Set rtfs.database.type to postgresql to point RTFS at a separate database.

Architecture

When you configure rtfs.database, Artifactory and RTFS on a single JPD use independent database connections:

┌──────────────────────────────────────────────┐
│ JFrog Platform Deployment (JPD)              │
│                                              │
│  Artifactory  ◄──►  Artifactory database     │
│       │          (Oracle, MySQL, MSSQL,      │
│       │           or PostgreSQL)             │
│       ▼                                      │
│  RTFS         ◄──►  Separate 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 separate 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 a separate 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 a separate 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 for its own datastore. 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