We have been using the beaver builder a while now and are noticing that BB is adding a lot of data to the size of the database. For example, we have a site at http://micropulsewest.com with around 25 pages but the database is about 360MB. Most of that data (358MB) is in the wp_postmeta table and looking at that table, a large percentage of the data in there has a meta_key of _fl_builder_data.
We have another site (not using BB) that is an ecommerce site and has 25,000 products in WooCommerce yet the database is less than 100MB.
The micropulse site is only an example, we have another site using BB that is the same way…over 350MB with only a few dozen pages.
Is this normal for BB to make the database so huge? We have used Visual composer before and not seen such huge db sizes for relatively small websites.
Is it possible for you to export your database, zip it up and share it with us so we can take a closer look, please?
Unfortunately, it’s too large for my apps to open. Is it possible for you to provide FTP access, temp admin access and access to PhpMyAdmin, please?
I’ve spoken to one of our developers and they have informed me that there is a fix going to be included in the 1.7.6 update which may address this issue. As it is related to another issue that is similar to yours.
When 1.7.6 is released, please keep us informed if it resolves your issue or not.
So do you mean to say that when that update is released it should fix already existing sites with respect to the database size issue?
Or will the update only prevent new sites from having unusually large databases?
I did some more testing and it looks like I was incorrect about that fix. Sorry about that!
The issue appears to be that you have 2770 rows with the
_fl_builder_data key in the post meta table.
Do you really have that many pages using Beaver Builder? Or is it possible that you just need to clean up revisions (which typically bloat the DB)?
Let me know.
We only have 27 pages in the site and there are no revisions at all.
You have access to the WP admin so you should be able to see that.
We are really needing to understand why there are so many rows from BB in the database.
It’s been a full 7 days now since this issue was brought up and it doesn’t seem we are getting any closer to understanding why there are so many BB rows in the database.
My apologies, this is a particularly tricky issue that has never come up before. Beaver Builder uses standard WordPress functions to insert/update/delete its post meta (update_metadata, etc.), so I’m not quite sure what could be causing the excess rows. I’m going to do some more testing against the database shortly and get back to you.
So you know, we have another site that has the exact same issue. Less than 30 pages, but the DB is over 350MB. We haven’t run into this with sites not using BB plugin. We are using BB theme on both the affected sites too.
Did you have revisions running at any point in time during the development of this site? There are a lot of post IDs in the post meta table that don’t exist with
I’m still trying to figure out why, but my initial guess is that there were revisions and something deleted them but didn’t delete our post meta. I’m still digging but let me know about that.
We do use the WP Optimize plugin for managing revisions. It auto-deletes any revisions older than 2 weeks.
I’ve done quite a bit of testing on my dev install but am still failing to recreate the issue of orphaned post meta that you are experiencing. I had roughly 50 pages/templates using the builder, deleted them all, and all of the
fl_builder* post meta was deleted as well.
I created, edited, duplicated, saved revisions, etc., and still can’t recreate it. I’m definitely not trying to push the issue off on you, but it does seem like something out of the ordinary is causing this to happen since we’re using standard WordPress functions to work with post meta.
It does look like this plugin can help you clean up the orphaned rows. Would you be willing to give that a shot? If so, keep an eye on it and let us know if it happens again and if there is anything in particular about your workflow that you think might be causing it. I’m definitely happy to continue diagnosing this issue if there is something we can pinpoint that might be the cause.
Sorry, it looks like we posted at the same time. Thanks for the info, I’ll do some testing with that plugin.
After doing some testing with WP-Optimize it definitely looks like that is causing the issue with revisions. It makes sense that only our data would be there since storing post meta in revisions isn’t something that WordPress does by default. Plugin authors like us that need revisions of their meta stored must take additional steps to make that happen. We’re probably the only plugin you have installed doing that.
There might be other issues with WP-Optimize causing orphaned post meta, but it looks like a ticket was opened on GitHub about this and has yet to be resolved. I tested on my end with a post that had revisions as old as five months and can confirm the issue.
I’m going to follow up on that issue, but for now, you’ll have to look at options for cleaning up orphaned post meta until they get this resolved. My apologies for the hassle, I wish I had a better answer for you.
Do you know if that WP Cleanup plugin you recommended will remove those orphaned metadata records? Tring to figure out how to clean up this issue on these 2 affected sites.
Unfortunately, I don’t have any experience with that plugin or cleaning up orphaned post meta, but they do say they handle it. A quick Google search also brings up this result with a query you could run…
It also looks like the WP Sweep plugin will do this…
You should be fine as long as you take a backup of the database before trying any of these out.
My apologies again for the hassle.