...Then there's an inefficiency in the design.
You should store in the primary database in the most compressed, compact form you can that can still be accessed in reasonable time. Tokenise as well, if it'll help.
The customer should never be accessing the primary database, that's a security risk, the customer should access through a decompressed subset of the main database which is operating as a cache. Since it is a cache, it will automagically not contain any poorly-selling item or item without inventory, and the time overheads for accessing stuff nobody buys won't impact anything.
If you insist on purging, there should then be a secondary database that contains items that are being considered for purge as never having reached the cache in X number of years. This should be heavily compressed, but where you can still search for a specific record, again through a token, not a string, then add a method by which customers can put in a request for the item. If there's still no demand after a second time-out is reached, sure, delete it. If the threat of a purge leads to interest, then pull it back into primary. It still won't take up much space, because it's still somewhat compressed unless demand actually holds it in the cache.
This method:
(a) Reduces space the system needs, as dictated by the customer and not by Amazon
(b) Purges items the system doesn't need, as dictated by the customer and not by Amazon
The customers will then drive what is in the marketplace, so the customers decide how much data space they're willing to pay for (since that will obviously impact price).
If Amazon actually believe in that whole marketplace gumph, then they should have the marketplace drive the system. If they don't actually believe in the marketplace, then they should state so, clearly and precisely, rather than pretend to be one. But I rather suspect that might impact how people see them.