GI Numbers, UIDs, and Ensembl Stable IDs

By the end of this lesson you will be able to look at any of the numeric or coded IDs NCBI and Ensembl throw at you — a bare integer like 1732746264, an Entrez UID, or a stable ID like ENSG00000012048 — and know exactly what each one is, which system owns it, and which one a tool actually wants. That saves you from the classic beginner mistake: handing a database the wrong flavor of identifier and getting an empty result.

GI numbers: the original integer key

Before accessions were the front door, NCBI identified every sequence record by a GI number (GenInfo Identifier) — a plain, ever-increasing integer with no prefix and no meaning you can read off it. When BRCA1's curated mRNA is fetched today, its GI is 1732746264. That number tells you nothing about the molecule; it is just the next ticket NCBI issued when that exact sequence entered the archive.

The critical thing about a GI is that it is version-specific. In Versioning: accession.version and Why Records Change you learned that when a record's sequence is edited, its version bumps from NM_007294.3 to NM_007294.4. Each of those versions carries its own GI number — the edit mints a brand-new integer. So a GI pins you to one exact sequence, but it is opaque and, since NCBI's 2016 policy shift, no longer the identifier you should build on.

Entrez UIDs: the per-database index key

A UID (Unique Identifier) is the internal integer key that Entrez — NCBI's search system — uses to index records inside one database. Every Entrez database has its own UID space, and the same gene wears a different UID in each:

So "GI number" and "UID" are not rival systems — for sequence databases, the UID is the GI. For the Gene database, the UID is the Gene ID 672 you met in A Field Map of the Major Databases. The word "UID" just names the role — the integer Entrez indexes on for this db — rather than a single numbering scheme.

This matters the moment you script Entrez. ESearch (the search endpoint) returns a list of UIDs; EFetch and ESummary take UIDs back to pull the records. Each call is scoped to one db, and the UIDs only mean anything inside that db.

accession.version is now the primary ID

Here is the modern rule: for sequence records, accession.version is NCBI's primary identifier, and the GI has been demoted to a legacy alias. An accession is the stable, human-readable ID whose prefix you learned to decode in Reading a Prefix: Provenance and Molecule Type — NM_ says curated RefSeq mRNA, and NM_007294.4 names one exact version of it.

E-utilities still accept a GI wherever they accept an accession, so old scripts keep working. But you can and should ask for accessions instead of GIs by adding idtype=acc:

# Returns the GI integer (legacy default)
esearch -db nucleotide -query "NM_007294" | efetch -format uid

# Returns NM_007294.4 — the accession.version, the primary ID
esearch -db nucleotide -query "NM_007294" -idtype acc

Ensembl stable IDs: ENSG, ENST, ENSP

Ensembl — EMBL-EBI's genome browser — never used GIs. It gives every feature a stable ID: a typed, prefixed code designed to stay constant across genome releases even as the annotation underneath is refined. The prefix names the feature type:

Read ENSG as ENSembl Gene, ENST as transcript, ENSP as protein, followed by an eleven-digit zero-padded serial number. (Non-human species insert a species tag — mouse genes are ENSMUSG… — but for human the tag is omitted.)

Stable IDs carry their own .version suffix, and it works just like NCBI's: the ID stays fixed while the version increments when the underlying model changes. Today BRCA1 is ENSG00000012048.28 at the gene level and ENST00000357654.9 at the transcript level — the .28 and .9 will keep climbing across future Ensembl releases, but the stable-ID stem will not move. Strip the suffix when you need the release-independent identity; keep it when you need one exact model.

That transcript, ENST00000357654, is the same physical BRCA1 mRNA as RefSeq's NM_007294 — the two are sequence-identical, matched up by an agreement between NCBI and Ensembl that pairs one RefSeq accession with one Ensembl stable ID per gene. Hold the shape for now: NCBI names it with an accession, Ensembl names it with a stable ID, and both resolve to the one molecule.

Which ID do I hand a tool?

The quick decision rule: give NCBI E-utilities an accession.version (or a UID if the tool demands one), and give the Ensembl REST API a stable ID. Never mix them — an ENSG means nothing to Entrez, and a GI means nothing to Ensembl. Get this pairing wrong and a script that looks correct will simply come back empty, because you handed the right kind of question to the wrong system.