Proposal for Optimizing Liferay Object Storage Architecture

Currently, Liferay stores object-related data in the Object Entry table and the individual Object Tables created for each object. For example, if we have two objects—Customer and Vendor—Liferay creates separate tables for each. When a new entry is added to the Customer table, a corresponding row is also inserted into the Object Entry table. The same applies to the Vendor table.

Over time, as more objects are created and each object table accumulates a large number of records, the Object Entry table becomes a performance bottleneck due to its centralized nature and growing size.

Recommendation: I propose decoupling the Object Entry table from individual object tables. Instead of maintaining a centralized Object Entry table for all objects, each object should manage its data independently within its own table. This architectural change would:

Reduce overhead on the Object Entry table
Improve scalability and performance
Simplify data management for high-volume object tables

This change would be particularly beneficial in environments with a large number of custom objects and frequent data operations.

I believe same schema sharding can also add significant performance and scalability. Like 1-1000 object entries can be sharded into a new table for the same object. This ways instead of having a single huge object table, we could have multiple tables for the same object.

Thanks for your suggestion, @Vasantharajan_Aruljothi ! I’ve passed it onto the team for evaluation, if I hear anything I’ll let you know.

Since the object entry table holds only the meta data that links with actual object data and proper index, with pagination on api’s it should not be a bottle neck. Audit is one of the example table that handles huge data.