Choosing a Helix ALM database format

Helix ALM uses SQLite for the native backend database format. The server database and projects can be stored in other RDBMS types, such as Oracle, PostgreSQL, or SQL Server. See RDBMS Support for information about supported platforms and database versions.

Consider the following when choosing a database format.

  • Administration—The native database format does not require much advanced administration. Other RDBMS databases usually require some administration to optimize speed, set up backup processes, and more. If you are considering using another RDBMS database type, we recommend working with an experienced database administrator. See the database vendor help for best practices.
  • Set up—When using a native database, the Helix ALM Server automatically creates the entire database. When creating other RDBMS databases, the server can create all of the tables, but the physical database must already exist. Your administrator should create the physical database so they can change the configuration for your environment. When using a SQL Server database, you must also create an ODBC data source name (DSN) so the server can find the database.
  • Database licenses—Native database functionality is bundled with your Helix ALM licenses and does not require additional licenses. Licenses for other RDBMS databases are not bundled with Helix ALM. You may need to purchase additional database licenses.
  • Reporting—Helix ALM’s built-in reports are available regardless of the database format. Helix ALM also has external reporting plug-ins you can use to create reports using third-party reporting tools, such as SQL Server Reporting Services or Crystal Reports. Additional reporting utilities are included with some RDBMS databases. If your company has expertise with other reporting tools or has existing data in a specific RDBMS database format, this may help you choose a database format.

The following considerations should not impact your decision when choosing a database format.

  • Speed—In our testing, operations resulted in similar timing for native and other RDBMS database formats. We selected the native database format in part for its quick speed.
  • Backups—Back up databases on a regular basis to protect against hard drive failures, viruses, or other corruption. All of the supported database types can be backed up, but the processes are different. See the server admin utility help for information about backing up native databases. For information about backing up other RDBMS databases, see the database vendor help.
  • Configurability—For both native and other RDBMS databases, you can configure field names, custom fields, workflows, notification rules, and more. Use a Helix ALM client to make these changes instead of making them at the database level. Do not change database table or column names, modify column size or attributes, or make any other structural database changes. These types of changes result in errors running Helix ALM.
  • Live updates—Helix ALM caches data to improve the performance of complex operations. Do not perform live updates of data at the database level unless the Helix ALM Server is shut down. To perform data update, use SOAP, bulk field changes, or other methods available from Helix ALM.