The Pega^® Platform relational database contains the rules, data instances, work items, history, and other concrete objects from the internal classes of your Pega Platform system. External classes correspond to tables in other databases and are not part of the Pega Platform database. You can use Oracle, IBM, or Microsoft relational database products for your database. Pega Platform builds on the performance, reliability, integrity, scale, and backup features that these mature databases provide.

Detailed knowledge about the database is not needed for most application tasks. Designers can create rules and properties, and save data without updating the database structure and without the need for a database administrator. However, the overall performance of your system — both the interactive response time experienced by users and the total throughput — depends on following good application design and implementation practices. Pega Platform provides several built-in tools to help you understand how well the database is operating and where to focus efforts to tune or improve performance. These tools include Database Trace, Performance Analyzer, Query Inspector, and Schema tools.

Database tables

The Pega Platform database contains the permanent data for all Pega Platform applications stored in the Pega Platform database's many tables. The rows of each database table correspond to saved objects of one or more classes. The columns of each table, with the exception of the BLOB column as explained below, correspond to properties (data values or fields) in the object. For example, information about each user, known as an operator ID, of the system is saved as a row in the pr_operators table. If your system has information for 340 users, this table has 340 rows. The pyOrganization column contains the name of the organization that the user belongs to, such as "MyCo Inc." The pxInsName column contains the text value of the key to the row, for example, "[email protected]". Column names that start with px or py correspond to standard, built-in properties.

As users interact with a Pega Platform system, database rows are automatically created, updated, saved, deleted, and searched to reflect the user's inputs, decisions, and the results of calculations. One user action, such as approving a request that allows work to progress through a flow, might cause updates to multiple rows in multiple tables. Database facilities ensure that all updates occur simultaneously (known as a transaction commit) so that the content of the database is always up-to-date and consistent. Internally, these updates are sent to the database software as Structured Query Language (SQL) queries.

Multiple servers might be required to provide enough processing power to support hundreds or thousands of users. In such a "cluster" approach, all servers connect to a single, central database. For example, Mary in the Florida office might update case W-4315 at noon Florida time. A moment later, Harry in the Kansas office might review the history of case W-4315, accessing a different server. Harry's screen reflects Mary's changes.

For performance and design reasons, not every property in a class corresponds to a column in a database table. Values of some properties are saved in a compressed form in the pzPVStream column, which is often called the BLOB (binary large object) column. For example, the Operator ID form records the full name of the user in a property named pyUserName. Unlike the pyOrganization property, the pyUserName property is typically not a column, meaning that the user name is saved with other property values in the pzPVStream value.

Properties that correspond to columns in a table are known as "exposed" properties. At times, for performance or reporting reasons, the database might be tuned to expose properties that were previously not exposed.

Key features of the Pega Platform database

Built on industry-leading database products

By using popular and established databases, Pega Platform realizes the technical benefits provided by well-known vendors: reliability, uptime, power, and scalability to a total size of a terabyte or more. For Pega Cloud customers, many database administrative tasks are performed by Pega Cloud operations. For more information, see Database maintenance for the Pega Cloud 2.1 database. For on-premises customers, administration, security, analysis and backup tools are available from the database vendors and from other suppliers.

Hidden and unobtrusive

Most application tasks do not require knowledge of the database structure or an understanding of SQL if the designers follow good design practices. Database tuning and optimization tasks, if needed for high-volume production systems, can often be performed by specialists without requiring changes to the Pega Platform application.

Evolutionary

The database structure can evolve during application development as needed without disrupting work. For example, use the Modify Database Schema wizard to view, or modify, in specific, limited ways, the columns of a specific database table (in development systems) without taking Pega Platform offline or waiting for a database administrator. The wizard provides a guided process to planning and making such changes.

Many-to-one class mapping

To limit the complexity of the database, each table can contain rows that correspond to several distinct, but related, concrete classes. The system uses pattern inheritance to locate which table has rows for particular classes.

Split-schema and single-schema configurations

You can configure your database as split-schema (recommended) or single-schema. In a split-schema, a rules schema contains rules tables and associated data and objects, and a data schema contains transaction data, including work objects. In a single-schema configuration, one schema contains all the rules and data objects.

If you plan to use a Pegasystems-supplied application and would like to store any non-Pega-specific data in a separate schema, you can optionally configure a separate customer data schema in addition to the default Pega data schema.

For more information, refer to the Deployment Guide for your system.