We currently have a property whose corresponding database column (PostgreSQL) is configured with a length of approximately 4,097 characters. This column is optimized in production as well. Due to new business requirements, we now need to support values up to 20,000 characters.
The property retrieves its value from a data page, and the data page is successfully returning all 20,000 characters when executed independently (I tested it using the pyGUID). However, when we try to display the value in the UI, only the first 4,000 characters appear—consistent with the column’s current DB limit.
We are considering the following approaches:
Increase the column size to 20,000 characters in the database.
Drop the dedicated column so that the value is stored in and loaded from the BLOB.
However, both options have drawbacks:
Approach 1 increases metadata usage, enlarges the table row size, and results in significant database growth.
Approach 2 may cause performance degradation since values will need to be fetched from the BLOB.
Could you please suggest if there are any additional approaches or advise on the most optimal solution for this scenario?
If you are not using the large string for search, you can use it in blob itself. If using for search, you can expose and define size as 20000. As you are using for display purpose that is fine. You should not be using that column for reporting purposes. Then it shouldn’t be an issue. We are fetching an xml blob(50000) from external system and we need to store it in data table for few months. We will be cleaning the data in few months based on the date data got stored.
The simplest fix here is to just bump the column size to 20,000 characters. People worry it’ll bloat the database, but PostgreSQL doesn’t work that way — it only stores what’s actually there, not the maximum size you set. So storage-wise, we’re fine.
The BLOB option sounds appealing but it has a real catch — every time a case opens, Pega has to load the entire BLOB just to read one field. That’s like opening a whole filing cabinet just to read one sticky note. It works, but it’s wasteful and will slow things down over time.
Also, if anyone ever needs to run a report or search on this field, a dedicated column lets you do that. BLOB-stored values are basically invisible to the database — you can’t query them directly.
The change itself is also dead simple — one database command and a small update in Pega. No data migration, no big redesign, nothing scary.
So really — low effort, no real downside, and it keeps things running the way you already do today. That’s a win.
Hi @AzaharuddinM : Can help to understand the use case better? Where are you using this property value? Is this in a case or in Data instances? How the data is represented? (multiple as in a table or single?)
When you say the datapage is returning the whole value but the UI is with limited characters, can you also check the data page used in the view?
Regarding the question on the Column exposure or fetching from BLOB, this really depends on the use case. Assume you have a view to show details of a object, then i don’t see a issue with fetching from BLOB. If the use case is on listing, then you need to consider about performance. There will be definitely impact in performance with the increase in data but will not be severe for single object pages when compared to list pages.
