Sounds like a quite fast solution but you should bear in mind that it is possible (especially with ISBN) that numbers are assigned to more than one product. Regarding ISBN many publishers re-use numbers after some time so you could run into the problem that you scanned the numbers correctly but later retain the wrong information for that number.

A better solution could be to additionally save some self generated information together with that scanned number to be able to verify the data later or to retrieve the data in real time and to verify the received data immediately. That would probably take more time but you'd be sure to have correct information. I bet you are not able to check 1000 items from memory after having them scanned in one go! Especially insurances are extremely unhumorous when detecting wrongly declared items! In worst case you'd lose complete insurance because of one wrong entry!

Another argument against scanning before retrieving is the possibility that some items might not be available via amazon or some other database. Then you'd see just some long numbers without any other information and would have to dig the whole bunch for that special item. NO FUN

Regarding suitability of sqlite for that size of database: no problem at all. You are talking about a database with some thousands of entries, likely less than 10.000 entries. You could start thinking of some more mature database when handling some millions of entries! A spreadsheet instead would be no good for that purpose as they are meant for handling less data in one table (even if they offer the ability to store some 10k of rows in one table).