on write write to new schema and delete from old one
on read read from both schemas

this plan will also go through two phases, the first for property terms and the second for item terms.

when old wb_terms is empty, read only from new schema and drop wb_terms table eventually

This plan will actually not require extra space (other than usual dbms needs for schema/meta info on tables and indexes) and will result in reducing the total space usage over time.

It is hard to estimate the footprint of this plan on performance, which is likely to be a little higher than the original one. If I can think of a way to estimate I will share some numbers soon.

rollback plan

Stopping and rolling back here is more complicated. If performance degradation was the reason to rollback, then we might be very much stuck. Reason is that we cannot just stop as in "we stop dealing with new schema immediately and just switch back to write and read from old wb_terms", because we would have already deleted some data from wb_terms and moved them over to new schema.

So stopping here would mean to "migrate back" in which we: on write we write to old schema and delete from new schema, and on read we read from both until new schema is empty. That would not release us immediately from the degradation in performance as we would wish.