Problem/Motivation

  • #3030154: layout_builder__layout_section column hitting database limit says that in some cases a single layout builder section record can contain >64kb of serialized data.
  • Every node revision creates a new record in the node_revision__layout_builder__layout table for each section, even for sections that have not changed.
  • This can lead to large database sizes.

Steps to reproduce

Proposed resolution

  • Create a new table that maps a hash (e.g., sha2) of the serialized section data to that data.
  • Store only that hash in the layout_builder__layout_section column.
  • An even further optimization would be to remove inline custom blocks' block_revision_id from the section data before generating the hash, and to have a separate database column containing those block revision ID values. That way, for the case where you edit the layout and the only edit made is to edit the fields of an inline custom block, then the new revision would generate the same section storage hash.

Remaining tasks

Discuss whether or not this is a good idea.

User interface changes

API changes

Data model changes

Release notes snippet

CommentFileSizeAuthor
#15 Screenshot 2025-06-05 at 5.01.41 PM.png23.17 KBkunalkursija
#6 image (3).png541.59 KBpodarok

Comments

effulgentsia created an issue. See original summary.

effulgentsia’s picture

effulgentsia commented
Issue summary: View changes
effulgentsia’s picture

effulgentsia commented
Issue summary: View changes

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

podarok’s picture

podarok
🇺🇦 he/him/his
Primary language Ukrainian
Location Ukraine
commented
Category: Feature request » Bug report
StatusFileSize
new image (3).png541.59 KB

Hi.
Thanks for this issue.
I'm changing this from feature request to bug request because on production this is getting rough
Example
https://www.drupal.org/files/issues/2023-02-07/image%20%283%29.png

203 nodes with Layout Builder enabled, which have 3-132 revisions, 6-12 sections on every node equal 1.2Gb of table size, which is a nightmare for backup/restore and local/dev imports/builds.

From our investigation - the majority of the sections are unchanged.
layout_builder__layout_section column of node_revision__layout_builder__layout table contains serialised Object of respective section.

Improvements we may have
- Make this table/column as COMPRESSED on DB level ( more workaround, not actual fix )
- move these sections to other table via hash/id
- make section as revisionable entity and instead of keeping it within node_revision__layout_builder__layout table - use reference to the section revision.

On heavy sites with a lot of Layout Builder
nodes*revision*section = a lot of disk space and slowness.

Bug is
- we keep copy of the serialized object in layout_section column for every delta in every other revision - waste of space

Solution
- We need to avoid keeping copy of same data and use references/joins in DB going forward

steinmb’s picture

steinmb commented
Issue tags: +Performance
hmdnawaz’s picture

hmdnawaz commented

Is someone working on this? No progress from the last year?

I have the same issue. The total size of the database is 1.2GB. In which 982MB is only this table node_revision__layout_builder__layout.

podarok’s picture

podarok
🇺🇦 he/him/his
Primary language Ukrainian
Location Ukraine
commented

re #8 - we installed node_revision_delete and set some values to keep DB size in control, but still root cause wasn't solved

catch’s picture

catch
he/him
Primary language English
commented
Priority: Normal » Major

Bumping this to major, this could result in sites going out of disk space on some hosting plans - lots of specific restrictions on database size.

solideogloria’s picture

solideogloria commented

I think this is a good idea as well.

hmdnawaz’s picture

hmdnawaz commented

Any update on this issue? or any workaround instead of using node_revision_delete?

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

ihamadet’s picture

ihamadet commented

For now, even node_revision_delete won't delete revisions in node_revision__layout_builder__layout.
I created a feature request to ask for this to be included in node_revision_delete: https://www.drupal.org/project/node_revision_delete/issues/3388227

kunalkursija’s picture

kunalkursija commented
StatusFileSize
new Screenshot 2025-06-05 at 5.01.41 PM.png23.17 KB

The node_revision__layout_builder__layout table can get very large on content-heavy enterprise sites—mine is over 20GB. I'm planning to regularly truncate old revisions in production to manage its size. It's not ideal, But a workaround.

andyf’s picture

andyf commented
Related issues: +#3469082: Add way to "intern" large field item values to reduce database size by 10x to 100x for sites with many entity revisions and/or languages

It seems to me there's a lot of overlap between this and #3469082: Add way to "intern" large field item values to reduce database size by 10x to 100x for sites with many entity revisions and/or languages, although there's the mention of optimizing for inline blocks in this ticket.

An even further optimization would be to remove inline custom blocks' block_revision_id from the section data before generating the hash, and to have a separate database column containing those block revision ID values. That way, for the case where you edit the layout and the only edit made is to edit the fields of an inline custom block, then the new revision would generate the same section storage hash.

Is it worth postponing on that and leaving this as a potential optimization?

catch’s picture

catch
he/him
Primary language English
commented
Status: Active » Postponed

Yes I think we should postpone this on #3469082: Add way to "intern" large field item values to reduce database size by 10x to 100x for sites with many entity revisions and/or languages, that would implicitly fix the issue for a lot of different fields then.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.