Repository navigation
Add uuid as feature types #5885
Description
Is your feature request related to a problem? Please describe.
Support random uuid and time uuid features is missing.
Describe the solution you'd like
We should add support for random and time based uuids as feast feature types.
Describe alternatives you've considered
We can store uuids as strings but then burden of converting back to uuid is on calling client. Also, we won't be able to add logic to transformation which uses uuid and time based uuid.
Additional context
Random uuid will be mapped to uuid4() in python and time based uuid will be mapped to uuid1().
Activity
[-]Add new uuid types[/-][+]Add uuid as feature types[/+]soooojinlee commentedon Jan 24, 2026
Hi! I'm interested in taking on this issue and wanted to confirm the expected scope.
My understanding of the minimum requirements for UUID support is:
Allow declaring UUID as a dtype for Features/Entities
When retrieving online features, return uuid.UUID objects instead of plain strings
Ensure UUID values are preserved correctly in on-demand transformations
The issue also mentions supporting uuid1 / uuid4.
Could you clarify whether these should be separate types, or if handling the version within a single UUID type is sufficient?
If everything above aligns with what you expect, could you also assign this issue to me?
Thanks!
franciscojavierarceo commentedon Jan 24, 2026
UUIDs are strings and time stamps are supported types. Are those primitives insufficient?
Can you give a sample transformation that outlines the gap?
nquinn408 commentedon Jan 24, 2026
@franciscojavierarceo I agree. The reason to add is two fold. First, the burden should not be on user to convert. It could affect latency and betrays point of disambiguating definition from serving. Second, the underlying storage may utilize it. For example, Cassandra is able to range queries over time uuids.
nquinn408 commentedon Jan 24, 2026
Wonderful!
I just want the conversion to be clear for user both in definition and when reading. If python reads back as uuid only, then it is ambiguous.
Sure!
nquinn408 commentedon Jan 31, 2026
@soooojinlee , I am unable to assign this issue to you, but feel free to pick it up in a separate issue. Thanks!
franciscojavierarceo commentedon Jan 31, 2026
Assigned!
feat: Add UUID and TIME_UUID as feature types (feast-dev#5885)
feat: Add UUID and TIME_UUID as feature types (feast-dev#5885)
feat: Add UUID and TIME_UUID as feature types (feast-dev#5885)
feat: Add UUID and TIME_UUID as feature types (feast-dev#5885)
feat: Add UUID and TIME_UUID as feature types (feast-dev#5885)
feat: Add UUID and TIME_UUID as feature types (feast-dev#5885)
feat: Add UUID and TIME_UUID as feature types (feast-dev#5885)
feat: Add UUID and TIME_UUID as feature types (feast-dev#5885)
feat: Add UUID and TIME_UUID as feature types (feast-dev#5885)
feat: Add UUID and TIME_UUID as feature types (feast-dev#5885)
feat: Add UUID and TIME_UUID as feature types (feast-dev#5885)
feat: Add UUID and TIME_UUID as feature types (feast-dev#5885)
feat: Add UUID and TIME_UUID as feature types (feast-dev#5885)
feat: Add UUID and TIME_UUID as feature types (feast-dev#5885)
feat: Add UUID and TIME_UUID as feature types (feast-dev#5885)
feat: Add UUID and TIME_UUID as feature types (feast-dev#5885)
feat: Add UUID and TIME_UUID as feature types (#5885) (#5951)
feat: Add UUID and TIME_UUID as feature types (feast-dev#5885) (feast…
chore(release): release 0.61.0
chore(release): release 0.62.0