ultravin

An extremely fast, fully offline NHTSA vPIC VIN decoder, written in Rust.

VINs decoded per second: ultravin 94,030 batched on 4 cores / 29,568 single-core vs corgi v3 83, corgi v2 33, NHTSA MSSQL 22.5, NHTSA Postgres 19.5
_{VINs decoded per second over a random corpus, single sequential caller — ultravin also batches across cores.}

⚡️ ~0.038 ms per decode — orders of magnitude faster than the NHTSA SQL procedures (corgi, Postgres, MSSQL)
🦀 Pure Rust core, shipped as a Python library and a Rust crate
📦 The entire vPIC vehicle database baked into the wheel
🔌 Fully offline — no network, no database, no data files at runtime
🎯 Byte-for-byte parity with vPIC's spVinDecode, verified across every decodable VIN — except documented vPIC defects, which ultravin deliberately does not reproduce (the registry, evidence)
🐍 Installable via pip, with a CLI and a library API
🧵 Batches in parallel to ~94,000 VIN/s on 4 cores
🗃️ Parquet in, parquet out — decodes a dataset of any size in the memory of one chunk

ultravin is a faithful port of NHTSA's spVinDecode — the SQL procedure behind vPIC — reimplemented in Rust and verified against the reference Postgres implementation. Because the vehicle database ships inside the binary, decoding needs no network, no database server, and no data files. Install it and decode.

Getting Started

Installation

uv add ultravin

Prebuilt wheels require Python 3.10+ and nothing else — the data ships inside the wheel.

Usage

From Python:

import ultravin

r = ultravin.decode("1HGCM82633A004352")

r["model_year"]  # 2003
r["wmi"]  # '1HG'
r["check_digit_valid"]  # True
r["error_codes"]  # [0]

# `attributes` is the decoded vehicle, one entry per vPIC variable:
r["attributes"]["Make"]  # 'HONDA'
r["attributes"]["Model"]  # 'Accord'

decode(vin) returns a dict with keys vin, wmi, descriptor, model_year, error_codes, check_digit_valid, corrected_vin, and attributes — a single variable -> value mapping. Values are str, except the free-text note fields listed in ultravin.MULTI_VALUED, which are always list[str]: those are the only vPIC elements allowed to repeat within one decode, and each row is a separate note rather than a competing value.

Decode many at once with decode_batch:

results = ultravin.decode_batch(["1HGCM82633A004352", "5YJ3E1EA7JF000000"])

If you already know a vehicle's model year, pass it — the same optional hint the vPIC API calls modelyear. It matters for pre-2010 vehicles, where the VIN's year character is ambiguous (A means 1980 or 2010): the hinted year gets its own decode pass that competes against the VIN-derived one, and a hint that contradicts the decoded year adds error code 12.

ultravin.decode("1HGCM82633A004352", year=1995)  # decodes as a 1995
ultravin.decode_batch(vins, years=[2011, None, 1987])  # one entry per VIN

Provenance: `full=True`

The default keeps the value and drops the provenance. If you need to know where a value came from — source, over half of all rows being vehicle-type defaults rather than something the VIN encodes — or the raw vPIC attribute_id, pass full=True:

r = ultravin.decode("1HGCM82633A004352", full=True)

r["elements"][0]  # {'variable': 'Make', 'value': 'HONDA', 'source': 'Manu. Name', …}

full=True replaces attributes with elements, a list of per-attribute dicts (group_name, variable, value, element_id, attribute_id, source, pattern_id, …), and works the same on decode_batch, decode_json and decode_batch_json. It is ~2× slower end to end: decoding is not the expensive part, and elements costs ~615 dict entries per VIN against the default's ~41.

ultravin.ELEMENTS maps each variable name to its static metadata (element_id, group_name, data_type, …). Pin to element_id if you need a key that survives NHTSA renaming a variable between data releases.

From the command line — every command emits JSON:

ultravin decode 1HGCM82633A004352             # JSON object
ultravin decode 1HGCM82633A004352 --year 1995 # with a caller model-year hint
ultravin decode 1HGCM82633A004352 --full      # with per-element provenance
ultravin decode-batch vins.txt                # one VIN per line -> JSON array
ultravin version

Rust

The engine is its own crate, ultravin: cargo add ultravin, then

let r = ultravin::decode("1HGCM82633A004352", None);
assert_eq!(r.model_year, Some(2003));

The 83 MB vPIC database is too big for crates.io, so the first build fetches it from the matching GitHub release, verifies it, caches it per machine and bakes it into your binary — runtime stays fully offline. Offline builds and runtime loading: crates/ultravin/README.md.

Datasets

For bulk work there is decode_stream — a stream of decoded Arrow batches, without a single row ever becoming a Python object:

import ultravin

rows = ultravin.decode_stream("registrations.parquet").to_parquet("decoded.parquet")

rows  # 4812004 — the rows written, not the rows themselves

The source is a parquet file, a directory of *.parquet read in sorted order, or anything speaking the Arrow C data interface — so the same call takes a pandas DataFrame (pandas ≥ 2.2, with pyarrow installed), a pyarrow Table, a polars DataFrame, a duckdb result, or a RecordBatchReader. A DecodeStream is itself an Arrow source, which is what lets it hand the decode straight to whatever you already use:

import pandas as pd, polars as pl, pyarrow as pa, duckdb

df = pd.DataFrame({"vin": ["1HGCM82633A004352", "5YJ3E1EA7KF328931"]})

pl.DataFrame(ultravin.decode_stream(df))  # -> polars
pa.table(ultravin.decode_stream(df))  # -> pyarrow
ultravin.decode_stream(df).to_pandas()  # -> pandas (needs pyarrow)

stream = ultravin.decode_stream(df)  # duckdb resolves the name from scope
duckdb.sql("select Make, count(*) from stream group by 1")

Each stream is single-use — note the fresh decode_stream(...) on every line above. It pulls from a source that has already moved on, so a second consumer would get a silently truncated result; consuming one twice raises RuntimeError rather than handing back a short answer. Call decode_stream again to re-read.

Picking columns

columns= takes vPIC variable names, element_ids, or both together; omit it for every publicly decodable element:

ultravin.decode_stream("registrations.parquet", columns=["Make", "Model", 13])

Pin to element_id for anything long-lived. The id is the one key NHTSA does not rename between monthly data releases.

Column naming and schema drift

Naming output columns after vPIC variables means a data refresh can silently change your table's shape — NHTSA renames variables, and Displacement (L) becoming something else takes every downstream query with it. column_names="id" labels each projected column attr_<element_id> instead, which never moves:

ultravin.decode_stream(src, columns=[26, 13], column_names="id")
# -> vin, decoded_model_year, attr_26, attr_13

Passthrough columns (the source VIN column, the source year column, and decoded_model_year) keep their own names in both modes; only the projection is renamed. The default is "variable" — reach for "id" when the output feeds a persisted schema rather than a human.

You never lose the other name. Every projected column carries both keys as Arrow field metadata, in both modes, and they survive the parquet round-trip:

table = pa.table(ultravin.decode_stream(src, columns=[26, 13], column_names="id"))
{f.name: dict(f.metadata) for f in table.schema if f.metadata}
# {'attr_26': {b'element_id': b'26', b'variable': b'Make'},
#  'attr_13': {b'element_id': b'13', b'variable': b'Displacement (L)'}}

Columns and layout

The VIN column is found by name (vin, case-insensitively) and then, for a parquet source, by sniffing the leading rows — as is the optional caller-year column (year, model_year, …); pass vin_column=/year_column= to name them outright. Any text encoding works: Utf8, LargeUtf8, Utf8View, or the dictionary a pandas categorical arrives as.

The output holds the VIN and caller year passed through, then decoded_model_year (named so it cannot collide with an input column called model_year), then one column per projected element — string, int64 or float64 following vPIC's own data_type, with an empty value written as null. Row order and row count always equal the input's: an undecodable VIN is a row of nulls, never a raise and never a dropped row.

For a parquet source, rows stream through in batch_size-row chunks with the GIL released, so peak memory is one chunk no matter how large the source is. For an Arrow source the producer decides the input chunking, and batch_size only sets the parquet row-group size of to_parquet. Reading and writing parquet is the same Rust as the decoding, so the parquet path needs no pyarrow and no other install; only the pyarrow/polars/pandas hand-offs need those libraries.

From the command line:

ultravin decode-parquet registrations.parquet decoded.parquet --columns Make,Model
ultravin decode-parquet parts/ decoded.parquet --columns 26,28 --vin-column chassis_no
ultravin decode-parquet registrations.parquet decoded.parquet --column-names id

Benchmarks

How many VINs each engine decodes per second, single sequential caller, over an identical random corpus of 5,000 valid VINs (measured over 60 s; Apple Silicon, batched across 4 cores):

engine	VIN/s	vs ultravin (1 core)
ultravin — batched, 4 cores	94,030	~3.2× faster
ultravin — 1 core	29,568	1×
corgi v3 — `@cardog/corgi` (binary index)	~83	~356× slower
corgi v2 — `@cardog/corgi` 2.0.1 (SQLite)	~33	~896× slower
NHTSA MSSQL — `spVinDecode` (SQL Server)	22.5	~1,314× slower
NHTSA Postgres — `spvindecode`	19.5	~1,516× slower
NHTSA vPIC web API — public rate limit	~10	~2,957× slower

ultravin runs in-process with the database embedded — no server, no round-trip. The corgi figures are derived from its project's published per-VIN latency (~12 ms v3 / ~30 ms v2, not re-measured here). The NHTSA Postgres and MSSQL oracles run the unmodified spVinDecode over localhost; MSSQL is SQL Server under amd64 emulation on Apple Silicon, so its number understates native hardware — ultravin is still ~1,314× faster. The NHTSA vPIC web API row is its published ~10 req/s rate limit, not a decode time — a hard ceiling regardless of hardware. Methodology and reproduction: docs/BENCHMARKS.md.

License

MIT. The embedded NHTSA vPIC data has its own provenance — see NOTICE.

Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Source Distribution

ultravin-2.0.1.tar.gz (21.2 MB view details)

Uploaded Aug 25, 2026 Source

Built Distributions

If you're not sure about the file name format, learn more about wheel file names.

The dropdown lists show the available interpreters, ABIs, and platforms. Enable javascript to be able to filter the list of wheel files.

ultravin-2.0.1-cp310-abi3-win_arm64.whl (25.3 MB view details)

Uploaded Aug 25, 2026 CPython 3.10+Windows ARM64

ultravin-2.0.1-cp310-abi3-win_amd64.whl (25.8 MB view details)

Uploaded Aug 25, 2026 CPython 3.10+Windows x86-64

ultravin-2.0.1-cp310-abi3-win32.whl (25.3 MB view details)

Uploaded Aug 25, 2026 CPython 3.10+Windows x86

ultravin-2.0.1-cp310-abi3-musllinux_1_2_x86_64.whl (26.0 MB view details)

Uploaded Aug 25, 2026 CPython 3.10+musllinux: musl 1.2+ x86-64

ultravin-2.0.1-cp310-abi3-musllinux_1_2_i686.whl (26.0 MB view details)

Uploaded Aug 25, 2026 CPython 3.10+musllinux: musl 1.2+ i686

ultravin-2.0.1-cp310-abi3-musllinux_1_2_armv7l.whl (26.2 MB view details)

Uploaded Aug 25, 2026 CPython 3.10+musllinux: musl 1.2+ ARMv7l

ultravin-2.0.1-cp310-abi3-musllinux_1_2_aarch64.whl (25.7 MB view details)

Uploaded Aug 25, 2026 CPython 3.10+musllinux: musl 1.2+ ARM64

ultravin-2.0.1-cp310-abi3-manylinux_2_31_riscv64.whl (25.8 MB view details)

Uploaded Aug 25, 2026 CPython 3.10+manylinux: glibc 2.31+ riscv64

ultravin-2.0.1-cp310-abi3-manylinux_2_28_aarch64.whl (25.5 MB view details)

Uploaded Aug 25, 2026 CPython 3.10+manylinux: glibc 2.28+ ARM64

ultravin-2.0.1-cp310-abi3-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (25.7 MB view details)

Uploaded Aug 25, 2026 CPython 3.10+manylinux: glibc 2.17+ x86-64

ultravin-2.0.1-cp310-abi3-manylinux_2_17_s390x.manylinux2014_s390x.whl (26.2 MB view details)

Uploaded Aug 25, 2026 CPython 3.10+manylinux: glibc 2.17+ s390x

ultravin-2.0.1-cp310-abi3-manylinux_2_17_ppc64le.manylinux2014_ppc64le.whl (25.9 MB view details)

Uploaded Aug 25, 2026 CPython 3.10+manylinux: glibc 2.17+ ppc64le

ultravin-2.0.1-cp310-abi3-manylinux_2_17_armv7l.manylinux2014_armv7l.whl (25.9 MB view details)

Uploaded Aug 25, 2026 CPython 3.10+manylinux: glibc 2.17+ ARMv7l

ultravin-2.0.1-cp310-abi3-manylinux_2_12_i686.manylinux2010_i686.whl (25.9 MB view details)

Uploaded Aug 25, 2026 CPython 3.10+manylinux: glibc 2.12+ i686

ultravin-2.0.1-cp310-abi3-macosx_11_0_arm64.whl (26.0 MB view details)

Uploaded Aug 25, 2026 CPython 3.10+macOS 11.0+ ARM64

ultravin-2.0.1-cp310-abi3-macosx_10_12_x86_64.whl (25.6 MB view details)

Uploaded Aug 25, 2026 CPython 3.10+macOS 10.12+ x86-64

File details

Details for the file ultravin-2.0.1.tar.gz.

File metadata

Download URL: ultravin-2.0.1.tar.gz
Upload date: Aug 25, 2026
Size: 21.2 MB
Tags: Source
Uploaded using Trusted Publishing? Yes
Uploaded via: twine/6.1.0 CPython/3.13.13

File hashes

Hashes for ultravin-2.0.1.tar.gz
Algorithm	Hash digest
SHA256	`6cbe9cd8ed38cc276fc3370b7237301d03dddc11fc629aa30cabbeecb94e81e1`
MD5	`cf912b9b9f3525f13deee3ba1cb499a7`
BLAKE2b-256	`a0f9249d8d1e80cef30b17d75dd9e6be0071505cd587043c5030e5404129caec`

Algorithm	Hash digest
SHA256	`ddb9982c3fe6f66ebb3e8c067f9cb06a1821f0104d5b7aae4f3b1915f6c5cd4f`
MD5	`96be985f2f7331a0236f96275475618f`
BLAKE2b-256	`5492e6922654b48ec8fd84b631b16d65ec739406ddaab1c8b8225611a6f07425`

Algorithm	Hash digest
SHA256	`5ccc6f1b9216dca72d87bcd9da4f3aafa3425cc0754f0ef2949329e2d639e353`
MD5	`a3f28864190ad891694261ab423944ee`
BLAKE2b-256	`cfaa98b7888b5168f26c7dab71da1427a47a9c6634658f5346c955b81b135d14`

Algorithm	Hash digest
SHA256	`408dc665c6b9717e9b6622b90d38ce98188fb17bdfb85d2f28d41348c3479551`
MD5	`e7ae0e945640a7cbedf8064c3e346b15`
BLAKE2b-256	`488a90af340e6a741d412598b42821fd0ea64e9aea18ae717251b9bf12d55cab`

Algorithm	Hash digest
SHA256	`1f620ca7c4ab6998134683030bac9a0855e3a9bfccee7cbb1ef5653b2d8c7665`
MD5	`ec14b2e2dd2e9337ef86f83813c1726b`
BLAKE2b-256	`d7547302dc413c50ebefba1638e599b1bd673981bc2bb0bb6d4a3be52873a3c8`

Algorithm	Hash digest
SHA256	`ae99027cd4b5dcbad7244f302e3041dd672126066801d3348d9cea4ddf94074c`
MD5	`075bc99054cf142dea1a5a118192c2ba`
BLAKE2b-256	`0178e1668de526845a9210805a5b93c9f5ba07e8c8c03a45eb45638c3da7f927`

Algorithm	Hash digest
SHA256	`5e5cd70bd228f37da54634acbf37b8dd95c045b671dec92221f43ee5fdb65889`
MD5	`85a08db1f4e3939e4a3cacc15515fbb2`
BLAKE2b-256	`c854346c5a24571378223b2998dc120d7d3d1ecbffd5c93ca63883607255e463`

Algorithm	Hash digest
SHA256	`ebee65a106b204f3f09e213154679f169406db40af2ac92e59d83a6f37fbaae5`
MD5	`c7e1a68963b352b7ba5451e45d9a8abf`
BLAKE2b-256	`4b6942729b59edbc75b0c4ff2253a21c0c3eb0b82b1a9461ff9cce0e996d6343`

Algorithm	Hash digest
SHA256	`e0cf3dd429aeac8efeb0ba469b4df9f0935d514da39c362a4482b50d2b231f8f`
MD5	`67d7af3f6b527f2ce89ce3d1d36f028b`
BLAKE2b-256	`61b0118460ccbbecfe60e6a51abd2c6eecd037e462d84d41b110685439e4c337`

Algorithm	Hash digest
SHA256	`9f1f85780d6a81b44d9317892753963f85749862cf2ee6c732ab99db13a6e1d7`
MD5	`fe733d1cb1e9880d2217d58a3427befb`
BLAKE2b-256	`9e9daa3a9ef12f8abdf0a1bfa8a6c19dcaa7565540062327f43d597c1665fee5`

Algorithm	Hash digest
SHA256	`6f0b321f78e9abb08e34267cdd47121e913cf45d921a29b34557f489dfc902e8`
MD5	`5a4c7a47ef565b3366296e8a13f2c4f0`
BLAKE2b-256	`7dcafaf7bb86565c7358d5cb9f2f1e6b844b0b7964803097ee3afc4b3e3f4c9d`

Algorithm	Hash digest
SHA256	`bad4f00bbff55f463b219fc57be1e639e646a52f9b4c44077eb66f3a76396884`
MD5	`ae848561a71e72f98c806e9e45880ac5`
BLAKE2b-256	`f73eefc0bc76090ccd9aed0b0b036c5d5a5ed1a275ff9fe42465593ba3b49663`

Algorithm	Hash digest
SHA256	`7234382e34c29348af0a49bc389673f906e11928d5a861051f3a62da15aadfcf`
MD5	`87abd7e84817d9ad014173ee67f71593`
BLAKE2b-256	`7c6a4c049e5503d17b1db8c4ebae2c1f8efcea6c8d09254436c24dc47b3dcbcb`

Algorithm	Hash digest
SHA256	`582e9d08145fe6efb5aba9622f23cb0af42a66e8657dd284b9366410e007f0ad`
MD5	`58dae2ed8bffbc24830cf936faa0bd3f`
BLAKE2b-256	`af726b47d1c9a755a7ab2fc90ff88c806233f48324b7e54e37f795fcb70f460f`

Algorithm	Hash digest
SHA256	`59ff5af9fd5187f18030e7db738f23c913630e9d07b72bf2a3c3adb4b5c64ad5`
MD5	`50b73e61c9c199fdab6e6f3345b0848b`
BLAKE2b-256	`499f63dc7068ba02660ed44f9fca08c8d27f159bc48d63f21e2860f7f56cb592`

Algorithm	Hash digest
SHA256	`cff4a9fb3fc00ae44b699fa20faaf628d6df1ad141b769c396bfcd0e3b92f7a2`
MD5	`cecdb94ff80689c58609a787e0d235b4`
BLAKE2b-256	`5cf894dbb1ce97ae9f22a18807be71294813ce071c4ee57aa329937a5a28098f`

Algorithm	Hash digest
SHA256	`78ceb399e2f0b75ff3dfb7f7cfe17633bf8b9f2633ce8825db942a0fe16475c2`
MD5	`cb29e4baf49b88749b928ab15877de72`
BLAKE2b-256	`150a0fbde34fe2913c130dc3f8da9fe82be8cc4afc6cf7c2939d99f2fdeccca2`

ultravin 2.0.1

ultravin

Getting Started

Installation

Usage

Provenance: full=True

Rust

Datasets

Picking columns

Column naming and schema drift

Columns and layout

Benchmarks

License

Project links

Key dates

1 maintainer

Credits

GitHub Statistics

License expression

Requires

Download files

Source Distribution

Built Distributions

File details

File metadata

File hashes

Provenance

File details

File metadata

File hashes

Provenance

File details

File metadata

File hashes

Provenance

File details

File metadata

File hashes

Provenance

File details

File metadata

File hashes

Provenance

File details

File metadata

File hashes

Provenance

File details

File metadata

File hashes

Provenance

File details

File metadata

File hashes

Provenance

File details

File metadata

File hashes

Provenance

File details

File metadata

File hashes

Provenance

File details

File metadata

File hashes

Provenance

File details

File metadata

File hashes

Provenance

File details

File metadata

File hashes

Provenance

File details

File metadata

File hashes

Provenance

File details

Provenance: `full=True`