WordPress saves a draft copy of every post every 60 seconds and keeps every revision indefinitely by default. On a site with a long writing history, that means thousands of extra rows in your database, all doing nothing but taking up space. Fix it with two constants in wp-config.php: one to slow the autosave interval, one to cap how many revisions each post keeps.
Edit wp-config.php
Open wp-config.php through the portal's File Manager tile, or connect over SFTP with an FTP account from the FTP Accounts tile. The file sits in your site's root directory. Add these two lines above the line that says /* That's all, stop editing! Happy blogging. */:
define('AUTOSAVE_INTERVAL', 120); // seconds
define('WP_POST_REVISIONS', 10);
AUTOSAVE_INTERVAL controls how often the block editor writes a draft copy while you're working. WordPress won't let it go below 60 seconds, but 120 or 180 is plenty for most writers and cuts the write frequency in half or more.
WP_POST_REVISIONS caps how many old versions of a post WordPress keeps before it starts deleting the oldest ones. Set it to a number like 10, or set it to false to turn revisions off entirely. Turning them off completely isn't usually worth it, since revisions are the only way to recover a paragraph you deleted by accident, but a cap of 5 to 10 keeps the history useful without letting it grow forever.
Save the file. The new limits apply the next time WordPress runs those actions.
Clean up what's already there
The two constants above only stop new revisions from piling up. They don't touch the ones already sitting in your database. To clear the backlog, open phpMyAdmin from the portal (Services → your hosting → phpMyAdmin) and run:
DELETE FROM wp_posts WHERE post_type = 'revision';
Adjust the table prefix if yours isn't the default wp_. This deletes every stored revision across every post, which is safe since the constant you just set will keep new ones capped going forward. If you'd rather not touch SQL directly, a cleanup plugin like WP-Optimize does the same thing through wp-admin, but for a one-time deletion the SQL query is faster and doesn't need a plugin left installed afterward.
After a large delete, it's worth running an OPTIMIZE TABLE on wp_posts from phpMyAdmin's Structure tab to reclaim the freed space on disk, rather than just marking it free.
Why this matters more on some sites than others
A low-traffic blog with a handful of authors won't notice thousands of stray revision rows. A busy site, especially a WooCommerce store with editors updating product pages constantly, accumulates them fast. Every extra row is something your database has to scan through on queries that touch wp_posts. If your site already feels sluggish, revisions are rarely the main cause. Work through My WordPress site is slow first, since heavy plugins, image weight, and theme bloat usually matter more.
It's also worth doing this cleanup before you create a staging copy, since staging clones your full database, revisions included. A leaner wp_posts table means a faster clone and less wasted space on the staging copy too.
If you'd rather not edit files
If editing wp-config.php directly isn't something you want to do, a plugin like WP-Optimize or Revision Control gives you the same settings through a wp-admin screen, plus scheduled cleanup so you don't have to run the SQL query again later. The tradeoff is one more active plugin, which is itself a minor performance cost, so the file edit is the better option for most people managing their own site.
Before making either change on a site you can't afford to break, take a fresh backup. Your account already runs nightly automatic backups, so you can restore from the portal's Backups tile if anything looks wrong after cleanup. If you'd rather not touch the database directly at all, open a ticket from Support in the portal and a real person can run the cleanup for you.