Set up External Database
TeamCity stores build history, users, build results, and some runtime data in an SQL database. See the full list of stored data here.
The currently used database is shown on the Administration | Global Settings page. It is also mentioned in
teamcity-server.log on the server startup.
HSQL* means that the internal database is in use.
Default Internal Database
On the first TeamCity run, using an internal HSQLDB database is suggested by default. The internal database suits evaluation purposes only; it works out of the box and requires no additional setup.
However, we strongly recommend using an external database as a backend TeamCity database in a production environment. An external database is usually more reliable and provides better performance: the internal database may crash and lose all your data (for example, on the "out of disk space" condition). The internal database may become extremely slow on large data sets (database storage files over 200 MB). Please note that our support does not cover any performance or database data loss issues if you are using the internal database. Migrate to an external database the moment you start relying on the data stored on your TeamCity server.
Selecting External Database Engine
As a general rule, you should use the database that suits your environment best and that you can better maintain/configure in your organization. While we strive to make sure TeamCity functions equally well under all the supported databases, issues may surface in some of them under high TeamCity-generated load.
You may also want to estimate the required database capacity.
Configure the external database to be used by TeamCity (see the database-specific sections below).
Configure the connection to the database via the form on the first TeamCity server start or by configuring the database connection settings manually.
Note that TeamCity assumes ownership over the database schema. The database structure is created on the first start and actively modified during the upgrade to the new TeamCity version. The schema is not changed when TeamCity is working normally.
The user account used by TeamCity should have permissions to create new, modify, and delete existing tables in its schema, in addition to usual read/write permissions on all tables.
You may also need to download the JDBC driver for your database.
Due to licensing terms, TeamCity does not bundle the driver
.jarfiles for external databases. You will need to download the Java JDBC driver and put the appropriate
.jarfiles (see driver-specific sections below) from it into the
<TeamCity Data Directory>/lib/jdbcdirectory.
Note that the
.jarfiles should be compiled for the Java version not later than the one used to run TeamCity. Otherwise, you might get the "Unsupported major.minor version" errors related to the database driver classes.
The section below describes the required configuration on the database server and the TeamCity server.
On MySQL Server Side
Recommended database server settings:
Use InnoDB storage engine.
Use utf8mb4 character set (or utf8 if MySQL version is 5.5.2 or earlier).
Use case-sensitive collation.
Make sure that the time zone of the JVM running TeamCity and that of MySQL instance are the same using the
my.cnffile or by configuring time zones at the OS level.
The MySQL user account that will be used by TeamCity must be granted all permissions on the TeamCity database. This can be done by executing the following SQL commands from the MySQL console:
On TeamCity Server Side (with MySQL)
JDBC driver installation:
Download the MySQL JDBC driver. Make sure to use a version compatible with your server. If the MySQL server version is 5.5 or later, the JDBC driver version should be at least 5.1.23. For versions above 8, driver version 8 should be used.
mysql-connector-java-*-bin.jarfrom the downloaded archive into the
<TeamCity Data Directory>/lib/jdbcdirectory (remove the existing files there, if any). Proceed with the TeamCity setup.
On PostgreSQL Server Side
Create an empty database for TeamCity in PostgreSQL.
Make sure to set up the database to use UTF8.
Grant permissions to modify this database to the user account used by TeamCity to work with the database.
TeamCity does not specify which schema will be used for its tables. By default, PostgreSQL creates tables in the
public schema. TeamCity can also work with other PostgreSQL schemas. To switch to a different schema, create a schema named exactly as the username. This can be done using the
pgAdmin tool or with the following SQL:
The schema has to be empty (it must not contain any tables).
On TeamCity Server Side (with PostgreSQL)
On Oracle Server Side
Create an Oracle user account/schema for TeamCity.
Make sure that the national character set of the database instance is UTF or Unicode.
CREATE TABLEpermissions to a user whose account will be used by TeamCity to work with this database.
On the first connect, TeamCity creates all the necessary tables and indices in the user's schema. (Note: TeamCity never attempts to access other schemas even if they are accessible.)
Make sure the TeamCity user has quota for accessing the table space.
On TeamCity Server Side (with Oracle)
Get the Oracle JDBC driver. Supported driver versions are 11.1 and later. The Oracle JDBC driver must be compatible with your Oracle server.
Place the following files:
ojdbc7.jardepending on your database version)
orai18n.jar(can be omitted if missing in the driver version)
<TeamCity Data Directory>/lib/jdbcdirectory (remove the existing files there, if any).
It is strongly recommended locating the driver in your Oracle server installation. Contact your DBA for the files if required. Alternatively, download the Oracle JDBC driver from the Oracle website.
Proceed with the TeamCity setup.
Microsoft SQL Server
For step-by-step instructions, see the dedicated page. The current section provides key details required for the setup.
On MS SQL Server Side
Create a new database. As the primary collation, use the case-sensitive collation (collation name ending with
_CS_AS) corresponding to your locale.
Create a TeamCity user and ensure that this user is the owner of the database (grant the user
dborights), which will give the user the ability to modify the database schema. For SSL connections, ensure that the version of MS SQL server and the TeamCity version of Java are compatible. We recommend using the latest version of the SQL server.
Allocate sufficient transaction log space depending on how intensively the server will be used. The recommended setup is not less than 1 GB.
Make sure the SQL Server browser is running.
Make sure the TCP/IP protocol is enabled for the SQL Server instance.
On TeamCity Server Side (with MS SQL)
Unpack the downloaded package into a temporary directory. Copy the
mssql-jdbc-*.jre11.jarfrom the just downloaded package into the
<TeamCity Data Directory>/lib/jdbcdirectory (remove the existing files there, if any). MS SQL integrated security (Windows authentication) requires installing
sqljdbc_auth.dllfrom the driver package as per instructions.
Proceed with the TeamCity setup.
It is not recommended using the jTDS JDBC driver, as it has known issues with using Unicode characters.
If you use the driver (
jtds text appears in the
database.properties), it is highly recommended switching the native driver:
Create the server backup including the database.
Stop the server and configure the server to use the native Microsoft JDBC driver as noted in the section above.
Restore the database from the backup into the new MS SQL database.
Run the server.
Database Configuration Properties
The database connection settings are stored in the
<TeamCity Data Directory>/config/database.properties file. The file is a Java properties file. You can modify it to specify required properties for your database connections.
For all supported databases there are template files with database-specific properties located in the
<TeamCity Data Directory>/config directory. The files have the
database.<database_type>.properties.dist naming format and can be used as a reference on the required settings.
TeamCity uses Apache DBCP for database connection pooling. Refer to Apache Commons documentation for detailed description of configuration properties.