Best way to build a Mega menu

[jacksoggetto]

I would love. amega menu on my website, and would love to control it from the backend.

How would you do it? I put a nested array in global, an the website was not usable anymore (I waited a few minutes to open the page, once nothing happened I reverted back to the original file.

• Payload 3.x with SQLite adapter
• Global config with nested arrays/blocks
• file: src/Header/config.ts

With only 3 nested levels was not usable:

{
  name: 'navItems',
  type: 'array',
  fields: [
    {
      name: 'label',
      type: 'text',
    },
    {
      name: 'megaContent',
      type: 'blocks',  // ← questo dentro array dentro Global = lentissimo
      blocks: [
        {
          slug: 'column',
          fields: [
            {
              name: 'links',
              type: 'array',  // ← array dentro blocks dentro array = ancora peggio
              fields: [...]
            }
          ]
        }
      ]
    }
  ]
}

NOTE: I need more than 3 nested levels for my mega menu

My current workaround: I moved the mega menu data to a static TypeScript file (src/Header/mega-menu.ts) and kept only simple fields in the Global (logo, clientAreaUrl, langFlag). The nav structure is hardcoded in TypeScript but typed and easy to edit (I don't like this solution at all though).

Questions:

1. Is nested array/blocks inside a Global a known performance issue with SQLite adapter specifically, or also with Postgres?
2. Is there a recommended pattern for CMS-driven mega menus in Payload 3.x? For example, using a separate Collection for mega menu panels with a relationship field in the Global navItems array?
3. Would moving to Postgres solve the admin performance issue with nested fields?

[manimovassagh]

The performance issue you're hitting is a known pain point with deeply nested arrays/blocks in Payload 3.x — it's not specific to SQLite, though SQLite makes it worse because of how Payload generates the join queries for nested structures.

Here's the pattern I'd recommend for a mega menu:

Use a separate collection instead of nesting everything in a Global.

Create a menu-items collection with a self-referencing relationship for hierarchy:

const MenuItems: CollectionConfig = {
  slug: 'menu-items',
  admin: {
    useAsTitle: 'label',
  },
  fields: [
    {
      name: 'label',
      type: 'text',
      required: true,
    },
    {
      name: 'link',
      type: 'text',
    },
    {
      name: 'parent',
      type: 'relationship',
      relationTo: 'menu-items',
    },
    {
      name: 'order',
      type: 'number',
    },
    {
      name: 'column',
      type: 'number',
      admin: {
        description: 'Which column this item belongs to in the mega menu',
      },
    },
  ],
}

Then in your Header global, use a simple relationship field:

{
  name: 'topLevelNav',
  type: 'relationship',
  relationTo: 'menu-items',
  hasMany: true,
}

On the frontend, fetch all menu items in a single query and build the tree in memory. This is way more performant than deeply nested blocks because:

1. Each menu item is a flat row in the DB — no nested joins
2. The admin panel stays fast because each item is edited individually
3. You can nest as deep as you want without performance degradation

To answer your specific questions:

1. It happens with Postgres too, but less severely. The issue is the number of joins Payload generates for nested structures, not the DB engine itself.
2. The collection-based approach above is the recommended pattern.
3. Postgres would help somewhat but won't fully solve it for 3+ nesting levels. The architectural change is the real fix.

[jacksoggetto]

Thanks for your reply!