How can I reclaim space after nulling out LONGTEXT records on MySQL?
Yes and no.

In InnoDB, "small" columns are stored with the record in a BTree.  "Large" columns are stored elsewhere.  The cutoff between small and large is complex.  So let me ask how big your LONGTEXT values actually are.

When you shrink something that is stored with the record, it is unlikely to free up any space other than in the one 16KB block in question.  This can be reused if some row is inserted or a column is updated to be bigger.

Or, if two adjacent BTree blocks are only half full, the engine may coalesce them, thereby freeing up a block.  More on free blocks later.

If you are NULLing a large value (let's say more than 3KB), then the space in the off-record storage is freed.  This will free up some number of blocks, depending on the actual size.

What about the freed up block(s)?  Well, they are parts of "extents".  Etc, etc.

Bottom lines:


Nulling a column may free up block(s)
Those blocks may be available for future activity.
The blocks will not be released back to the filesystem of the OS.  That is ibdata1 nor .ibd will shrink.


OK, I told you more than you needed.  Let me re-address the question of "Can I pay for a smaller VM by doing such NULLing?"

Again, Yes and no.

No, the disk allocation will not automatically shrink.

Yes, in that you could take action to give the space back to the FS.  Now, to discuss this...


OPTIMIZE TABLE blocks usage of one table, but shrinks its disk footprint if it had been created with innodb_file_per_table = ON.  Else, no benefit.
Dumping the entire database and starting over by reloading it on a fresh MySQL instance, will release space, regardless of the above setting.  But this is a big task.
Check with the VM provider.  They may have a way of doing that dump+reload.


To get an estimate of the disk space needed, see the SELECT in http://mysql.rjweb.org/doc.php/memory#another_algorithm .  But double what it gives you -- you do need space for various other things.