Unexpected jump in the Row IDs

Feedback
1

I am experiencing an unexpected jump in the Row IDs in my main buildings table and would appreciate your help investigating the cause.

I have been entering building records one by one. Initially, I imported a group of records in bulk, but since then I have added many records individually. Until recently, the Row IDs and my own Unique reference numbers followed the same sequential order.

The last record had Row ID 416 (added today, 25th October 2026). When I tried to create the next record, its Row ID was 440, leaving IDs 417–439 missing.

I have checked the following:

  • Switching between Row Identifier and Row Count: Row Count displays the records consecutively, but the Row IDs still jump from 416 to 440.
  • The Trash: none of the missing records appear there.
  • A temporary Formula field using row_id(): it returns the same IDs and confirms the same gap.

The new record with Row ID 440 is still empty. I have not found any evidence that the missing IDs correspond to records containing building data.

This is a relational database documenting contemporary architectural heritage. I have deliberately aligned the numeric suffix of each building’s Unique reference with its Row ID, so this unexpected jump disrupts my established data-entry workflow.

Could you please investigate why these IDs were skipped and whether this may be caused by a bug or another internal process? Is there any way to determine what happened to IDs 417–439?

I do not want to reset or modify existing IDs, as this could compromise the integrity of the database and its linked records. I would appreciate guidance on how to proceed safely and prevent this from happening again.

2

Gaps like 417–439 are usually normal: the row id comes from an auto-incrementing counter in the database, and it never reuses or renumbers values. Anything that consumes ids without leaving visible rows (a bulk create that was rolled back, an import or API batch that failed partway, a duplicate or sync that was reverted) can leave a hole like that. Since the Trash is empty and nothing is missing from your data, I wouldn’t worry about integrity, but I’d avoid treating the row id as a business key. A separate Unique reference field, maybe a formula or an autonumber field, is safer for your numbering workflow.

1 Like
3

Thank you for the explanation. It has also happened simultaneously with another table in the database (which I discovered after I sent the first message): row IDs jump from 499 to 524, leaving IDs 500–523 missing. Fortunately, these rows were empty, but it made me worry about the whole database. Is it possible that rows containing data might also go missing in the same way? What precautions should I take to prevent this from happening?