Question
700 Applications
IN
Last activity: 29 Nov 2025 19:03 EST
DB Table Naming Convention: Character Limits and Migration Best Practices
Dear All,
We have created a new Work class and its corresponding physical work table in our lower environment (DEV). When we migrate this configuration (via a Product Rule) to the QA environment, Pega attempts to generate a CREATE TABLE SQL statement using a different, auto-generated table name than the one used in DEV.
We observed that this discrepancy occurs because the intended table name exceeds 30 characters (the name is 36 characters long).
We understand we can work around this by manually running a SQL script in QA first to create the table with the expected name, and then importing the Pega code. However, we have two primary questions regarding Pega best practices:
- Is there a standard maximum character length for database table names that Pega officially suggests or adheres to? If we go beyond it any issue that we face? (Specifically, we want to know why Pega sometimes generates random, truncated names, and if we should rename them.)
- What is the recommended best approach for migrating database schema changes (like new tables/columns) from Development to higher environments? Should we rely solely on the Pega product import wizard, or is the standard approach to handle DB changes with SQL scripts first and then import the Pega code/rules?
Thank you.
HCA Healthcare
US
@DineshBhargav.V Pega follows the database’s own limits, so if you use Oracle you should keep table names at or under 30 characters, otherwise Pega or the DB will truncate or auto-generate shorter names and you’ll see the mismatch you observed. When a name is too long, Pega may generate a shorter internal name so the DDL will succeed, and that’s why you see unexpected names in higher environments. As a good practice, always keep Pega DB table names short, consistent, and within the DB limit instead of relying on the auto-generated ones. For schema migration (new tables/columns), the safest pattern is: DBA runs the DDL scripts first in higher environments (generated from DEV or from Pega’s schema tools), then you import the Pega product/rules and point the class to the already-created table. You can sometimes let the product import create the table in lower environments, but for QA/Prod it’s better to use controlled SQL scripts managed by the DBA team. This avoids surprises with truncated names, permissions, and schema drift between environments.