Database Size is growing too big!

  • 1 August 2021
  • 7 replies


Recently, I noticed the database of my website is growing too fast! I checked it in PhpMyAdmin and found out most of the issues relate to postmeta table and Elementor meta fields. Elementor were adding more than 80,000 records to the postmeta fields and caused my Database grows fast. 

I have around 30 Elementor pages in my website and I think it shouldn’t increase the size of my DB this much!

Any advice for reducing the size of my database?



Thanks in advance.


Best answer by Brian Johnson 14 October 2021, 16:06

View original

7 replies

Userlevel 1
Badge +2

You need to learn what is the cause of the increase database size.


I use advanced database cleaner pro to optimise. 

Userlevel 2
Badge +1

I am wondering this, too. I found a wp_options setting that is 536K! This is ONE option, named elementor_remote_info_library 

Then there is another that is 73K, elementor_remote_info_templates_data.

Here are some I have encountered and their sizes:

28K elementor_pro_remote_info_api_data_3.3.5

27K elementor_pro_remote_info_api_data_3.3.3

27K elementor_pro_remote_info_api_data_3.3.2

25K elementor_pro_remote_info_api_data_3.3.1


There ARE guidelines that say not to put so much stuff into the wp_options table.


“If you want to store options that are large in size, please consider using WP Large Options.  This plugin will store options in a custom post type and prevent the wp_options table from getting too large.

Data that might be a good fit for using WP Large Options:

  • Large HTML fragments
  • Any CSS (though we recommend storing this in theme files instead)


It also mentions, “only store the bare minimum amount of data in wp_options”


Checking into PHPmyadmin to see, there are 67 elementor-related options that are set for autoload.

SELECT *, char_length(option_value) FROM `wp_options` where option_name  like '%elem%' ORDER BY char_length(option_value) DESC

Combined this is 876K. That is a hefty chunk of data for one plugin. Admittedly it is an important plugin, but does all of this need to be stored in wp_options? Does it need to be set for autoload?


There are lots of other cautionary references about bloating the wp_options.

where it is recommended to keep the size below 500 rows. So if Elementor is using 13% of this budget at the get-go, what about other plugins? In a site where I have WooCommerce and Yoast as well, I’m looking at around 1650 rows in the wp_options table. So it’s not ALL Elementor’s fault that the wp_options table is so huge, but still, it is a good chunk.

My site has high DB Autoloaded data, and Elementor might be the cause of it.

In WordPress, the database holds many of your site’s settings. These settings can include a list of active plugins, your active theme, your site’s URL, theme settings, plugin settings, and more. The wp_options table in your database is where these settings are stored. Sometimes themes and plugins like to store extra items there, like Transients, long lists of redirect rules, and other lengthy settings. In this table there is a column labeled “autoload” which generally tells WordPress: does this setting need to be loaded on every page by default? If the answer is “yes” for some of these extremely lengthy settings, that’s extra data and bytes that WordPress has to load on your pages. Too much content set to “autoload” will lead to high Time to First Byte, and slow query performance in general.

I ran report on the site specifically regarding Autoloaded Data, and here are the findings. The database has 388 of 504 rows set set to Autoload = yes in the wp_options table, which is very good. However, the maximum recommended number in bytes of autoloaded data is 800,000 and of course, the lower the better. It seems your site is using 755,180 bytes, which is under the threshold, but could be better. Here is a break down of the top 20 options that load on every single page load and how many bytes they use up.

| LENGTH(option_value) | option_name |
| 127712 | elementor_pro_remote_info_api_data_3.2.1 |
| 127391 | elementor_pro_remote_info_api_data_2.5.8 |
| 76173 | ad47b1c423907501a2c250dfb97a9949 |
| 74595 | edd_api_request_ad47b1c423907501a2c250dfb97a9949 |
| 72535 | 9eed5cbf9882a8e5fbafd9d46132f098 |
| 42897 | redux_builder_amp |
| 35893 | elementor_pro_remote_info_api_data_3.3.4 |
| 27848 | elementor_pro_remote_info_api_data_3.3.3 |
| 27646 | elementor_pro_remote_info_api_data_3.3.2 |
| 26796 | elementor_pro_remote_info_api_data_3.3.1 |
| 26286 | elementor_pro_remote_info_api_data_3.3.0 |
| 24605 | elementor_pro_remote_info_api_data_3.2.2 |
| 8525 | rewrite_rules |
| 5612 | seopress_pro_option_name |
| 4433 | wp_rocket_settings |
| 4250 | wp_user_roles |
| 3565 | wpseo_titles |
| 3342 | cron |
| 2607 | wphb_settings |
| 2576 | seopress_google_analytics_option_name |

So it seems the elementor_pro_remote_info_api_data system seems to want to store a lot of data. I was able to trace that back to the /elementor-pro/ Plugin. It may be best to reach out to the author of that plugin to see if all that data is really necessary to "autoload" or if there could be a bug in the system that the author might be able to fix. Also, sometimes there are settings or configurations you might be able to adjust that might help reduce the bytes loaded.

Userlevel 2
Badge +1

Hi @Skyviewlv ,  You mentioned: “I was able to trace that back to the /elementor-pro/ Plugin. It may be best to reach out to the author of that plugin...” 

I am not sure, perhaps I have been misinformed, but I was thinking this forum right here, was where we reach out to Elementor Pro?  I had sort of hoped that they would be reading this forum and perhaps answering questions like this. (I would be baffled if they did not; for the money they must be rolling in they could hire scores of hungry interns to read these messages.)

To the general group, if one of you has time, see if you can change the autoload to this type of record--- those prefixed with _elementor to “no” or false or whatever and see if it works. If I can figure out an easy way to do it via PHP I will post my results.


Hey Brian,


Thanks for the reply. 


Sky View LV

Userlevel 6
Badge +1

… I was thinking this forum right here, was where we reach out to Elementor Pro?  I had sort of hoped that they would be reading this forum and perhaps answering questions like this...


@elementor, do you copy? Can you respond?

Userlevel 2
Badge +1

This just in, from Cyrus at Elementor Tier 2 Technical Support (vip-support). If any of you have followup questions, I will forward in a couple of days. The Kinsta link he refers to has a mind-blowing amount of information on this topic. One thing stands out: “137 MB [in autoload data]… is a good example of a site where something is definitely wrong...”

  • For myself, I am wondering about deleting the data; I suspect it would just come back the next time Elementor does an update.

Perhaps a fix for this is forthcoming, however, I would urge any other VIP plan members lobby for this, referencing this URL.


Hi Brian,

Thank you for contacting us.

The data you are referring to is the changelog information that is stored for the most recent plugin version update. It is available there so you can always see what is changed in the latest update. Instead of only setting their autoload value to "false", please feel free to remove that data manually, however, I would recommend making a full DB backup first.

Additionally, you can always do some extra optimization work described in this article -

We apologize for the inconvenience. This has been reported to our development team and I would like you to know that they are working on optimizing Elementor so it generates fewer data like this in future updates.

If you come across any other inquiry/issue using Elementor, please don't hesitate to open a new ticket; we'd be happy to help.

Kind regards,
Elementor Tier 2 Technical Support