pushid generator

Push ID is a unique identifier format created by Firebase, Google's real-time application platform, to serve as automatically generated keys for data stored in the Firebase Realtime Database. Introduced as part of the Firebase JavaScript SDK, Push IDs were designed to solve a specific problem: generating client-side keys for concurrent writes to a shared, hierarchical data store without requiring any server-side coordination. Before Push IDs, developers working with real-time databases often relied on server-generated auto-incrementing keys, which created bottlenecks and latency in highly concurrent environments. Firebase engineers needed an identifier that any client device could generate independently while still producing keys that sort in chronological order, making them ideal for ordered lists, chat messages, and event streams. The format has since become a widely recognized pattern for generating time-sortable, collision-resistant identifiers in client-side and real-time applications beyond the Firebase ecosystem.

Each Push ID is a compact 20-character string. The character set is a modified base64 alphabet specifically chosen so that standard lexicographic string comparison produces chronological ordering. This is a critical design decision: unlike standard base64, which uses an alphabet where character ordering does not correspond to numeric ordering, Firebase's modified alphabet ensures that a simple string sort on Push IDs will always arrange them from oldest to newest. This property eliminates the need for timestamp parsing or numeric conversion when querying ordered data, which is essential for the performance characteristics of the Firebase Realtime Database.

How Push ID Works

A Push ID is composed of two distinct segments within its 20-character string. The first 8 characters encode a millisecond-precision Unix timestamp. The remaining 12 characters are filled with cryptographic randomness. Together, these two segments produce a 120-bit identifier that is both time-ordered and collision-resistant.

The timestamp portion uses the current time in milliseconds since the Unix epoch (January 1, 1970). This 48-bit timestamp value is encoded into 8 characters using the modified base64 alphabet, which contains 64 characters arranged so that their lexicographic order matches their numeric value. Because the timestamp occupies the most significant (leftmost) characters, Push IDs generated at different milliseconds will always sort in the correct chronological order through simple string comparison.

The random portion fills the remaining 12 characters with 72 bits of cryptographically secure random data. This randomness is generated using the best available entropy source on the client platform. However, the random component has an additional property that distinguishes Push IDs from many other identifier formats: monotonic incrementing within the same millisecond. When multiple Push IDs are generated during the same millisecond on the same client, the generator does not draw entirely new random bytes. Instead, it increments the previous random value by one. This guarantees that IDs produced in rapid succession on a single client will sort in exact generation order, even if the system clock has not advanced. If the clock does advance to a new millisecond, a completely fresh set of random bytes is generated, resetting the sequence.

This monotonic increment strategy means that the effective collision domain is limited to IDs generated at the exact same millisecond on different clients. With 72 bits of randomness in that scenario, the probability of a collision remains astronomically low, even at global scale. The design supports millions of concurrent clients generating IDs without any realistic risk of duplicate keys.

Use Cases

Real-time messaging and chat applications. Push IDs were purpose-built for this scenario. In a chat application backed by Firebase Realtime Database or a similar real-time data store, each message can be stored under a Push ID key. Because the IDs sort chronologically, retrieving messages in order requires no additional sorting logic or secondary indexes. New messages from any user on any device will automatically appear in the correct position within the ordered collection, even if multiple users send messages in the same millisecond.

Event logging and activity feeds. Any application that records a stream of events, such as user actions, analytics events, or audit log entries, benefits from Push IDs as record keys. The chronological sorting property means that querying for recent events or paginating through historical data is efficient and straightforward. Since the IDs are generated client-side, events can be logged even when the client is temporarily offline and will merge into the correct order when connectivity is restored.

Collaborative editing and conflict-free data structures. In applications where multiple users are simultaneously editing shared data, Push IDs can serve as operation identifiers or as keys for conflict-free replicated data types (CRDTs). The monotonic ordering within a single client ensures that operations from one user maintain their intended sequence, while the timestamp component provides a global partial ordering across all participants.

Distributed task queues and job scheduling. Push IDs work well as job identifiers in distributed queue systems. Workers can process jobs in chronological order by simply iterating through keys in lexicographic order. The lack of coordination requirements means that any producer can enqueue jobs independently, and the natural ordering of Push IDs ensures fair, time-based processing without a centralized sequencer.

Comparison with Alternatives

Push ID and ULID share many fundamental properties: both are time-sortable, both embed a millisecond timestamp, and both append randomness to ensure uniqueness. The key differences lie in their encoding and standardization. ULID uses Crockford's base32 encoding to produce a 26-character case-insensitive string with a formally specified 128-bit structure (48-bit timestamp plus 80-bit randomness). Push ID uses a custom modified base64 alphabet to produce a shorter 20-character string with a 120-bit structure (48-bit timestamp plus 72-bit randomness). ULID has a written specification and broad cross-language support, while Push ID originated as an implementation detail of the Firebase SDK and has been reverse-engineered and ported by the community. If you need a standardized format with maximum cross-platform compatibility, ULID is the stronger choice. If you are working within the Firebase ecosystem or prefer shorter strings and are comfortable with the format's informal specification, Push ID is well-proven in production.

Compared to KSUID, Push ID trades some uniqueness guarantees for compactness and millisecond precision. KSUID is a 160-bit identifier (20 bytes) with a second-resolution timestamp and 128 bits of randomness, encoded as a 27-character base62 string. The additional randomness in KSUID provides a larger collision-resistance margin, and the format includes a custom epoch that extends its usable range. Push ID, with its 120-bit structure and millisecond timestamp, produces shorter strings (20 characters) and offers finer temporal resolution, which is advantageous for high-frequency event ordering. However, KSUID's extra 56 bits of randomness and its formal design as a standalone identifier format make it a more robust choice for systems that prioritize uniqueness above all else.

Push ID also differs from database-native sequential identifiers like auto-incrementing integers or Snowflake IDs. Auto-incrementing integers require a centralized counter, creating a single point of failure. Snowflake IDs solve the coordination problem but require pre-assigned worker IDs. Push ID requires no pre-configuration, no assigned worker identifiers, and no server communication, making it uniquely suited to client-side generation in environments like mobile apps and web browsers where network connectivity cannot be guaranteed. The trade-off is that Push IDs are longer than 64-bit Snowflake IDs and do not guarantee strict global ordering across clients within the same millisecond, only within a single client instance.