Overview

Artifactory comes with a built-in Derby database that can be reliably used to store data for production-level repositories (up to hundreds of gigabytes).
Artifactory's storage layer supports pluggable storage implementations (made possible by the underlying Jackrabbit JCR), so you can configure Artifactory to run with almost any JDBC database or even store data completely on the file system.

Once-and-Only-Once Identical Content Storage

Artifactory stores identical binary files only once. When a new file about to be stored in Artifactory is found to have the same checksum as an already stored file, Artifactory will not store the new file content, but will make a link to it in the metadata of the newly deployed file. This principal applies regardless of under which repository and path artifacts are deployed - you can deploy the same file to many different coordinates, and as long as an identical content was found in the storage it will be reused.

Changing the Storage Type Used

The general principal for changing the storage used by Artifactory is to edit the $ARTIFACTORY_HOME/etc/artifactory.system.properties file:

The path used can be either a relative path to $ARTIFACTORY_HOME/etc or an absolute path, and is expected to contain a repo.xml file (which is a Jackrabbit configuration file).

For a JDBC database you will also need to:

1. Download the appropriate JDBC driver and install it in your server's shared lib directory.
2. Create a database instance to which Artifactory will connect (when using an out-of-process database). Database tables will be auto-created.
3. Change the database details in the repo.xml file to match your database.

Backing up your existing installation When changing the storage type for an exiting installation you will need to import the old Artifactory content and configuration from backup. Make sure to back up your older Artifactory system before using a different storage type.

Removing the old $ARTIFACTORY_HOME/data folder If you already run Artifactory before with a different storage type you will need to remove (or move-aside) the existing $ARTIFACTORY_HOME/data folder, or Artifactory will still use part of the old storage definitions and will fail to start up (you will see record not found exceptions on startup). Starting with a clean or no $ARTIFACTORY_HOME/data folder will fix this.

Changes to repo.xml Except for updating the database details in repo.xml, do not make any other changes to the repo.xml file or try to manually replace it with a repo.xml from a newer Artifactory version. All changes to the repo.xml file as part of an Artifactory upgrade are always applied automatically.

When Artifactory is Deployed as a WAR

If you deployed Artifactory as a WAR and have not specified a location for the $ARTIFACTIORY_HOME directory, it will be auto-created by Artifactory under '$user.home/.artifactory'.
To use the bundled configuration files for common storage types, you may want to copy the etc/repo folder from the Artifactory distribution to your $ARTIFACTORY_HOME/etc. Then edit the $ARTIFACTORY_HOME/etc/artifactory.system.properties file as described above to point at the desired configuration.

The Bundled Storage Configurations

Out-of-the-box Artifactory comes with built-in configurations (repo.xml files) for the several storage types, as listed below.

Database Storage Types

The following configurations use a JDBC database for storage, and manage binaries as blobs with file system blob caching (1Gb by default)

1. derby (the default)
2. mysql - Please follow the MySQL-specific instructions
3. postgresql
4. oracle10
5. mssql

File System Storage Types

The following configurations store all binaries as files (in $ARTIFACTORY_HOME/data/filestore), and use a JDBC database for repository metadata management (managing repository metadata in plain files, is also possible but not recommended).
This setting typcially yields the best performance with large repositories.

1. filesystem-mysql - The recommended setup. Please follow the MySQL-specific instructions.
2. filesystem-derby
3. filesystem-mssql

For raw Artifactory data backup, the folder $ARTIFACTORY_HOME/data/filestore needs to be backed up in parallel of a DB dump since both are needed. This does not impact Artifactory's own backup system which is storage-agnostic.

Accessing a Remote Database

In order to avoid network latency issues when reading and writing artifacts data, it is highly recommended to create the database on the same machine on which Artifactory will be running or on a fast SAN disk.

This is critical if the files are served from database blobs and the file system cache size is low.