First of all, I’d use the Data Storage panel in the Company Information setup page to assess exactly which objects are the biggest contributors to your data storage usage. If Page Versions really are your biggest problem, and you’re using something like Skuid Grunt to do source control on your Pages, then you might consider setting the Page Version number down to 0 and just relying on Skuid Grunt + Source Control for maintaining historical versions of your Pages.

If you’re a registered Salesforce partner, you can usually request additional capacity via the Partner Community. If you’re just using a DE org to be able to deploy the same code to multiple Productions orgs that may be slightly different, you might want to separate out different functions into different DE orgs, for instance, if you’ve got a lot of test data that’s chewing up data storage space, maybe have a separate “QA” DE org where your larger test data setups exist, and have minimal test data in the DE org where Skuid Page development is occurring. That way in the QA org you won’t have Page Versions at all taking up data space, just the Skuid Pages and your test data sets, while in the “main” DE org you can have Page Versions but not all of the extensive test data.

Thanks, Zach.

Page Versions, Pages, and Page Interactions are the top three data hogs:

What are Page Interactions?

I just started using source tree, so I think I can eliminate page versions.