Title: Sudden ~1.72 billion gap in IDENTITY column between two ETL runs – what could cause this?

Adding to Erland's answer: there's one way an explicit identity value gets in without anyone running SET IDENTITY_INSERT, and it fits your numbers exactly. That's a bulk load that keeps source identity values.

Bulk-loading tools can insert explicit identity values themselves. Examples are .NET SqlBulkCopy with SqlBulkCopyOptions.KeepIdentity, the Keep identity option on an SSIS OLE DB destination, and similar "keep identity" settings in other copy tools. If a single row arrives with a large source ID, SQL Server makes that value the table's current identity value, so the next normal INSERT continues from it. Your first insert in run 2 was 1793678945, which is exactly what you'd see if a row was bulk-loaded with ID 1793678944 in between.

What I reproduced (SQL Server 2022, INT IDENTITY(1,1), no SET IDENTITY_INSERT anywhere in the code)

StepResultNormal insertsIDs 1, 2, 3Normal insertsIDs 1, 2, 3SqlBulkCopy with KeepIdentity, one source row with Id = 1793678944Row stored with ID 1793678944Delete that row (for example, a staging clean-up)No row left in the gapNext normal INSERT1793678945Same test without KeepIdentitySource ID ignored, next insert is 5, no jumpSo the stray row doesn't even need to still exist. The jump stays after the row is gone, which would also explain finding nothing between the two IDs.

How to confirm it

Check whether any rows are in the gap, as Erland suggested:

SELECT Id, *
FROM dbo.YourTable
WHERE Id > 73680612 AND Id < 1793678945
ORDER BY Id;

Search Query Store for bulk loads into the table (Query Store is on by default in Azure SQL Database). A bulk load shows up as an insert bulk statement, and when the identity column appears in its column list, identity values were supplied explicitly:

SELECT qt.query_sql_text,
       MAX(rs.last_execution_time) AS last_run,
       SUM(rs.count_executions)    AS runs
FROM sys.query_store_query_text  AS qt
JOIN sys.query_store_query        AS q  ON q.query_text_id = qt.query_text_id
JOIN sys.query_store_plan         AS p  ON p.query_id = q.query_id
JOIN sys.query_store_runtime_stats AS rs ON rs.plan_id = p.plan_id
WHERE qt.query_sql_text LIKE N'insert bulk%YourTable%'
GROUP BY qt.query_sql_text;

In my test, the KeepIdentity load appeared as insert bulk [dbo].[Orders] ([Id] Int, [Val] ...), while a normal bulk load appeared as insert bulk [dbo].[Orders] ([Val] ...). Look for a last_run inside your 7-minute window.

Check every process that writes to this table, not just people: Azure Data Factory or Synapse copy activities, SSIS packages, other ETL jobs and application services that use SqlBulkCopy, especially anything copying from another system where IDs could be in the billions.

Next steps

• Once you've found the source, turn off "keep identity" for that load, or map the source ID to a separate column.
• With about 353 million values left before the INT limit, plan the move to BIGINT as the AI answer suggested. Note that changing the type of an identity primary key means rebuilding the table and recreating its keys, so schedule it carefully.

Let me know what the Query Store query returns. If this explains it, please consider marking it as the accepted answer so others who hit the same jump can find it.

First of all, jumps with IDENTITY columns are perfectly normal. SQL Server only updates the value on disk for around every thousand value, so if there is an unclean shutdown, you may "lose" some value. Could certainly happen in Azure if there is a failover.

But 1.72 billion is certainly quite extreme, and not exactly normal. I'm afraid that what comes closest to mind is that someone, too smart for his/her own good, use SET IDENTITY_INSERT or DBCC CHECKIDENT. Did you check if there are any rows between the ids you list above? (Assuming that you got the ids from some other source the than the table itself.)

I looked at the two ids in hex: 0x046446E4 and 0x6AE95E61, but there is nothing that looks like some sort of corruption that flipped a bit.