If resume components are highly volatile and mostly text, I'd probably go for a simple KV table, instead of adding new columns to ResumeData. Then you could also put versioning there. Alternatives would be a JSON column or a proper table-per-component schema.
I wouldn't worry about "large data" if you're going with Postgres. You'll mostly enter that territory by storing lots of changes and updates, which just doesn't happen that much with a traditional