Best Practice: Pre-configuring 20 Extended Attributes during fresh Installation?

​I am currently performing a fresh installation of IdentityIQ 8.5. I’m considering extending the IdentityExtended and LinkExtended attributes to the maximum limit (20) right now, even though I don’t need all of them immediately.

​My goal is to use them as a ‘future-proof’ reserve to avoid having to modify .hbm.xml files or run manual ALTER TABLE commands on the MySQL database in the future when new business requirements arise.

  • ​Are there any significant performance concerns regarding indexing all 20 attributes from the start?

  • ​Is this considered a best practice in enterprise environments to avoid future schema migrations?

​I’d love to hear your thoughts or experiences on this. Thanks!"

Hi @cleber_pcarv,

It’s best to create an extended attribute when needed. IIQ includes some preconfigured extended attributes, I believe 15 (10 normal attributes and 5 identity-type attributes) for identity and 5 for others, if I’m not mistaken.

Considering that when you create a column, an attribute will be created for the table elements, even if it’s null.

Also, IIQ create those attribute like a 450 nvarchar for each attribute and if you follow this example you table have a lot of unused column with a a “large” size.

I suggest to you to optimize your db:

  • only columns you need
  • correctly sized columns (if the attribute is TRUE/FALSE, 5 nvarchars are sufficient, or 1 if used with 1/0)
  • dont create unnecessary indexes; only for columns that are frequently searched.

Create all the columns doesnt have a big impact if those columns are empty(NULL), but the impact exist(especially if you create them with indexes).

I recommend maintaining a clean database with only the elements you need. If you need a new column in the future, you can create it in 5 minutes.

PS I don’t know if I’m right to tell you, but you can create more than 20 extended attribute :sweat_smile:

Extending all 20 IdentityExtended and LinkExtended attributes upfront is acceptable, but indexing all of them from the start is generally not recommended. Unused indexes introduce unnecessary overhead during frequent write operations such as identity refreshes, aggregations, and provisioning. This can slightly degrade performance and increase database size without providing any immediate benefit. In enterprise IdentityIQ deployments, indexing is typically done only for attributes that are actively used in searches, rules, correlations, or reports. Schema changes to add indexes later are common, low risk, and well-understood in production environments. A practical approach is to pre-extend attributes for convenience but add indexes only when a real business use case emerges.

@cleber_pcarv You already have 20 extended searchable/indexed attributes available as a placeholder. Whenever you need them you just need to define them in Identity.xml or Identity Mapping. If you need more attributes, you can extend the columns and make necessary change in the IdentityExtended.hbm.xml file and identity mapping.

Note: Found a fix? Help the community by marking the comment as solution. Feel free to react(:heart:, :+1:, etc.) with an emoji to show your appreciation or message me directly if your problem requires a deeper dive.

SailPoint recommends using named columns during the fresh installation of IIQ and use extended attributes when requried. Creating all extended attributes and assigning indexes to each could cause DB performance contraints.

https://community.sailpoint.com/t5/Technical-White-Papers/Managing-Extended-Attributes/ta-p/77088

Hi @cleber_pcarv

No — don’t pre-create all 20 extended attributes.
Create only what you currently need.

Many people think:

If we add later → we must change hbm.xml → risky → let’s create all 20 now

This sounds safe. but in IIQ it actually causes performance and maintenance problems.

If you create 20 empty attributes:

  • DB still loads them

  • Hibernate still maps them

  • Identity Refresh still reads them

So even if unused, they increase:

• heap memory usage
• aggregation time
• identity refresh time
• certification load time.

Hope this is useful.

Note: Found a fix? Help the community by marking the comment as solution. Feel free to react(:heart:, :+1:, etc.) with an emoji to show your appreciation or message me directly if your problem requires a deeper dive