[GH-ISSUE #915] Switch to ByteAether.Ulid for faster, always‑reliable ULID generation #2662

New issue

Closed

opened 2026-03-01 17:22:23 +03:00 by kerem · 0 comments

kerem commented

2026-03-01 17:22:23 +03:00

Owner

Originally created by @Seramis on GitHub (Apr 21, 2025).
Original GitHub issue: https://github.com/1Remote/1Remote/issues/915

Originally assigned to: @VShawn on GitHub.

Hello!

First and foremost, thank you for the excellent work you've put into this project.

Please excuse the unsolicited suggestion. I was looking at the project dependencies and it started me thinking about the nuances of different ULID library implementations. Depending on the specific library in use, a couple of common issues can sometimes arise, and I wanted to share a thought in case it's helpful.

Many libraries have different approaches to the ULID specification, which can lead to a couple of potential outcomes:

Incorrect Monotonicity: Some libraries don't strictly enforce monotonicity. This can cause problems in systems that rely on the sortable nature of ULIDs, as it can result in out-of-order IDs being generated, especially under high load.
Overflow Exceptions: Other libraries, while adhering strictly to the spec, are designed to throw an exception if the random component overflows during high-frequency generation. This is a safety measure, but in a high-throughput scenario, it could unexpectedly halt ID issuance altogether.

To solve these exact problems, I ended up developing my own implementation. As a point of full transparency, I am the author of the library I'm about to suggest, called ByteAether.Ulid. I'm proposing it because I built it specifically to be a reliable and performant solution for these scenarios, and I thought it might be of value to this project.

A couple of key benefits:

Guaranteed Monotonicity without Exceptions: Instead of throwing an error on overflow, it gracefully increments the 48-bit timestamp. This ensures IDs are always sortable and that generation never fails unexpectedly.
Top-Tier Performance: It's benchmarked as being exceptionally fast and memory-efficient (zero allocation on generation), which is always beneficial.

If you're curious and have a moment, here are the links for your consideration:

GitHub: https://github.com/ByteAether/Ulid
Nuget: https://www.nuget.org/packages/ByteAether.Ulid/
Blog Posts with deep dives: https://byteaether.github.io/series/byteaether-ulid/

Again, I hope this comes across as a helpful suggestion from one developer to another.

Thanks for your time and for all your efforts on this great project!

Originally created by @Seramis on GitHub (Apr 21, 2025). Original GitHub issue: https://github.com/1Remote/1Remote/issues/915 Originally assigned to: @VShawn on GitHub. Hello! First and foremost, thank you for the excellent work you've put into this project. Please excuse the unsolicited suggestion. I was looking at the project dependencies and it started me thinking about the nuances of different ULID library implementations. Depending on the specific library in use, a couple of common issues can sometimes arise, and I wanted to share a thought in case it's helpful. Many libraries have different approaches to the ULID specification, which can lead to a couple of potential outcomes: 1. **Incorrect Monotonicity:** Some libraries don't strictly enforce monotonicity. This can cause problems in systems that rely on the sortable nature of ULIDs, as it can result in out-of-order IDs being generated, especially under high load. 2. **Overflow Exceptions:** Other libraries, while adhering strictly to the spec, are designed to throw an exception if the random component overflows during high-frequency generation. This is a safety measure, but in a high-throughput scenario, it could unexpectedly halt ID issuance altogether. To solve these exact problems, I ended up developing my own implementation. As a point of full transparency, I am the author of the library I'm about to suggest, called `ByteAether.Ulid`. I'm proposing it because I built it specifically to be a reliable and performant solution for these scenarios, and I thought it might be of value to this project. **A couple of key benefits:** * **Guaranteed Monotonicity without Exceptions:** Instead of throwing an error on overflow, it gracefully increments the 48-bit timestamp. This ensures IDs are always sortable and that generation never fails unexpectedly. * **Top-Tier Performance:** It's benchmarked as being exceptionally fast and memory-efficient (zero allocation on generation), which is always beneficial. If you're curious and have a moment, here are the links for your consideration: * **GitHub:** [https://github.com/ByteAether/Ulid](https://github.com/ByteAether/Ulid) * **Nuget:** [https://www.nuget.org/packages/ByteAether.Ulid/](https://www.nuget.org/packages/ByteAether.Ulid/) * **Blog Posts with deep dives:** [https://byteaether.github.io/series/byteaether-ulid/](https://byteaether.github.io/series/byteaether-ulid/) Again, I hope this comes across as a helpful suggestion from one developer to another. Thanks for your time and for all your efforts on this great project!

kerem

2026-03-01 17:22:23 +03:00

closed this issue
added the
meta-enhancement
label

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/1Remote#2662

No description provided.

Rows
Columns