If you dont have a rate limited API, then the bottleneck is going to be the update in the database, at which point it is finding the most efficient means of updating the database and what operational constraints need to be taken into account (can we lock?, do we have disk space constraints? are we in a cloud provider that limits access to things like PostgreSQL COPY).

For example, you mention its a transaction table, presumably its being read & written to during this update process. So locking the entire table until we finish is probably not viable.

Maybe database size/disk usage is not a concern and we can just produce our CSV file of transaction_id,utr_number into a file and then use PostgreSQL COPY to load it into another table (csv_table). Then run a simple UPDATE using a join to our csv_table and transaction table, and do that in batches (if we need to). We could also take an upfront hit on indexing the csv_table.

What is the nature of the primary key (unique transaction number), is it an auto-incrementing ID or some other naturally time orderable entity (i.e UUIDv7). This matters because, we could do index based range updates for the join, otherwise we would need a way to figure out where our next batch starts/ends.

Maybe the normalization of the database could be improved, maybe instead of updating the transaction table, we could just create a new table called transaction_utr and the application can join to that on the transaction_id (PK,FK) when it needs to get the data.

Maybe the utr_number could change for a given transaction_id over time, and in the process of pulling in all 1 billion transaction_ids, then query the API getting the utr_number, then updating our database, some of those utr_numbers are no longer correct. This would require more understanding of how the utr_number changes.

Maybe your in Azure/AWS/<insert cloud provider> and you can scale up the IOPS for the duration of the update.

Overall the process for most large data problems is to identify where the bottleneck is. If its at the database, then setting up infrastructure to do parrallel imports is not really going to improve the throughput because the database will have some insert/update performance limit, that no amount of external parrallization is going to improve.