Why and when to use " Flat Catalog"?

Difference between EAV catalog and Flat catalog is as following:

1. Eav Catalog

EAV is entity attribute value database model, where data is fully in normalized form. Each column data value is stored in their respective data type table. Example, for a product,

product ID is stored in catalog_product_entity_int table,

product name in catalog_product_entity_varchar table,

product price in catalog_product_entity_decimal table,

product created date in catalog_product_entity_datetime table,

product description in catalog_product_entity_text table.

EAV is complex as it joins 5-6 tables even if you want to get just one product’s details.

Columns are called attributes in EAV.

2. Flat Catalog

The flat model uses just one table, so it’s not normalized and uses more database space. It clears the EAV overhead,

It’s good when comes to performance, as it will only require one query to load whole product instead of joining 5-6 tables to get just one product’s details.

Columns are called fields in the flat model.

Magento implemented indexers that will periodically query the standard collections and populate flat database tables in the following format. Where * is store id.

catalog_category_flat_store_*
catalog_product_flat_*

These tables have the non-normalized product and category data that are intended to be read-only. This allows Magento to fetch category and product data in a single query.


You can enable flat catalog by navigating to System > Configuration > Catalog > Frontend > Use Flat Catalog Category | Use Flat Catalog Product. Set this to yes.

If you are adding a new attribute in the EAV table for the catalog. Then don't forget to run re-indexing (System > Configuration > Index Management). Re-indexing refreshes your flat catalog tables.

For more information please check “EAV” & “Flat Catalog” in Magento


Magento uses the Entity-Attribute-Value (EAV) model for storing customer, product, and category data in its database. Although the EAV model enables you to have completely extensible attributes for those objects, object attributes are stored in multiple tables rather than one very large table.

Because attributes are stored in many tables—and that includes copies of some of the same attributes—SQL queries can be long and complex. The flat catalog feature creates new tables on the fly, where each row contains all necessary data about a product or category.

In earlier versions of Magento, it was necessary to rebuild the flat catalog every time you made changes to product attributes or product-category associations. In this release, the flat catalog is updated for you—either every minute, or according to your Magento cron job.

Flat catalog options not only enable the flat catalog and flat product indexers but also enable indexing for catalog and shopping cart price rules. If you have a large number of SKUs (500,000 or more), Magento can index catalog and shopping cart price rules quickly if you enable the flat catalog product option.


Rohit's answer has been the percieved wisdom for the longest time but as of Magento 2.3 this is changing. It is no longer best practice to use flat catalog due to apparent "performance degradation and other indexing issues". While this seems counter intuitive, intial research seems to show this is due to reworking of how data is retrieved using Elatic Search.

Devdocs 2.3 screenshot

Some tweets here from the community with some Magento team involvement starts to shed light on this:

  • https://twitter.com/JigneX/status/1167552039813038087
  • https://twitter.com/theTiagoSampaio/status/1168938250989395969
  • https://twitter.com/lorenzi_jo/status/1171145687171383297

In Magento 1 this is irrelevant and is likely always advisable to use flat catalog as detailed in Rohit's answer