Proposal: Add a stable UUID/ULID “global ID” to core NetBox objects (without changing integer PKs)

[patrickpreuss]

Hi all,

I’ve seen a few related requests over time around “globally unique identifiers” and clustering/federation concerns—most directly the question about changing primary keys away from integers (#20067).
Rather than replacing integer primary keys (which would be a very large and disruptive migration), I’d like to propose a smaller step:

Proposal

Add a stable UUID/ULID field (e.g., uuid or global_id) to most/all core models in addition to the existing integer id primary key.

Why this helps

Instance-independent identifiers: External systems could reference objects without depending on an installation-local integer PK (which will collide across independent NetBox instances).

Future sync/replication/federation: A dedicated global identifier makes it easier to map objects between “share-nothing” NetBox installations, even if true multi-region clustering is out of scope today.

Precedent / recurring need: There have been requests for UUID-like identifiers to help correlate objects across systems (e.g., VMs).
Also, NetBox already uses a stored UUID field in at least one place (JobResult’s job_id).

Deterministic UUIDs (optional, for select object types)

For some objects (example: Device Type / “device model”), it might be useful to derive a deterministic UUID from stable attributes like manufacturer + sku, enabling “upsert by global ID” in imports and potentially reducing lookup work.

If deterministic IDs are considered, I’d suggest using UUIDv5 (name-based) rather than a raw MD5 hash, since it’s the standard mechanism for “UUID from name”:

import uuid

# Pick a project-specific namespace UUID (constant)
NAMESPACE = uuid.UUID("6ba7b810-9dad-11d1-80b4-00c04fd430c8")  # example

def uuid_from_name(name: str) -> uuid.UUID:
    return uuid.uuid5(NAMESPACE, name)

print(uuid_from_name("manufacturer=Cisco;sku=C9200L-24T-4G"))

(Deterministic IDs only make sense if the input fields are truly immutable; otherwise the ID changes when a name/SKU changes.)

import uuid
import hashlib

def create_uuid_from_string(val: str):
    hex_string = hashlib.md5(val.encode("UTF-8")).hexdigest()
    return uuid.UUID(hex=hex_string)

my_string = "Cisco SKU: C9200L-24T-4G"
print(create_uuid_from_string(my_string))

Questions for maintainers/community

• Would adding a secondary uuid/global_id field (unique + indexed) and exposing it via the REST API be acceptable, while keeping integer id as the DB primary key?
• Would you prefer UUIDv4 (random, generated once) everywhere, vs allowing UUIDv5/ULID for specific models/use-cases?
• Any concerns around migrations, API compatibility, plugin model inheritance, or database/index overhead?

Thanks!