refreshing 500k rows per day, what primary key to use? Usually I create a PK of type int/bigint for every table. But in this case I have some doubts.

I have a table which is updated many times a day, the total number of rows is around 500k, but they get refreshed few times a day.
Using update would be expensive, so for every batch of data to update I just delete the old rows (by a NC key) and bulkupload the new data.

Now my doubt is... I can just choose to have a bigint PK and forget about it, it will increase by 500k a day, and it will takes forever before to run out of values, but is there a better approach?
I'd stick with BIGINT.

An INT takes up 4 bytes of space. On 500,000 rows, that works out to 2 million bytes, or just under 2MB per day of overhead (which is practically nothing these days).

Double that for BIGINT, which is 8 bytes in size, so 500,000 rows will need under 4MB of space.

We generally recommend BIGINT if you're going to add (or change) over 2 billion rows over the lifetime of the table or index.

While INT supports a range of 4 billion values from roughly -2 billion to 2 billion, people generally start their IDENTITY value at 0 or 1, cutting out half of the available range.

In a case where you're doing 500,000 a day, a BIGINT might be better for you. It's a good trade-off between storage and data churn in the medium to long term.