Our team is running up against increasingly large appStoreReceiptURL sizes as users buy more and more subscriptions. Storing the receipt on the server backend, for future validation/expiration testing, is running into database column size limitations. Is there any way to deal with this other than increasing the size of the database column? That seems like delaying the inevitable to me.
appStoreReceiptURL size getting out of hand
There is no "need" to store anything other than used transaction_ids. The rest is for your own corporate needs. If they are not sufficient to justify adding additional columns then don't.
Is there a way to check on if a subscription has renewed or been cancelled or expired with just the transaction ids?
No. Any device logged into an iTunes Account under which there is an active autorenewable subscription, as long as the subscription was purchased from the device or the device executed a restoreCompletedTransaction, will receive a call to updatedTransactions with all the relevant info each renewal period.
Devices will receive a new transaction on each renewal and cancellation. Then the ApplicaitonReceipt is updated. Otherwise you can trigger a refresh manually, application-side.
I choose to keep the json server side also, purging the database from obsolete receipts on regular basis. If yours are getting too big you can implement some sort of incremental backup, storing only recent stuff and deleting the old transactions log from the application Receipt.