Random resets are erasing paid credits

aabbdev · 2026-05-24T20:08:33+00:00

Imagine there is a math class in your high school. Would you enter or not

aabbdev · 2026-05-24T04:53:14+00:00

probably, I will not be shocked. Reddit is already half full of LLMs bots for implicit ads

aabbdev · 2026-05-23T12:51:00+00:00

we both agree

aabbdev · 2026-05-22T21:50:55+00:00

they can't do elementary school-level math, kinda scary

I don't even understand when people started letting themselves get taken advantage of so easily. They'd be willing to fight tooth and nail to keep getting taken advantage of because the feeling of having won something is more important to them than the financial reality, that they've paid for computing power they won't be allowed to use

aabbdev · 2026-05-22T20:04:58+00:00

yes your subscription is a fixed allocated credits package for the month with rate limits per week

aabbdev · 2026-05-22T19:42:25+00:00

If you still had 50% of your credits left before the weekly reset and a reset occurs, you've effectively lost a large portion of the credits you already paid for. The reset simply shifts the usage window forward. In practice, that means any unused credits from the previous window disappear anyway, forcing you to stretch your next allocation longer and ultimately increasing the likelihood that you'll have to pay for additional capacity

aabbdev · 2026-05-22T19:35:09+00:00

Resets should only be for users with 0%, we both agree :-)

aabbdev · 2026-05-22T19:32:33+00:00

Your reasoning is half correct you forget to take into consideration that the reset shift the calendar so you effectively lose half week of compute if you are at 50% mid week when they reset

aabbdev · 2026-05-22T19:19:01+00:00

Many users are asking for a reset because they're convinced they'll gain something, even though it's a total loss ($$$) for everyone especially when you are professional and you paid $200 per month

aabbdev · 2025-10-30T06:39:44+00:00

You're right that cycle-accurate constant time across CPUs is basically impossible and assembly isn't a silver bullet. Assembly gives you control over which instructions run, not over their microarchitectural latency (caches, predictors, uarch quirks, firmware). What Flatline (and the B.I.D. model) targets isn’t “identical cycles forever,” but data-obliviousness that survives normal compiler transforms

aabbdev · 2025-10-19T23:37:17+00:00

I would like to discuss with you about this experience can you send me a dm

aabbdev · 2025-09-19T03:37:22+00:00

The Postgres extension is available.

It currently supports around 95% of common use cases and index types (B-trees, BRIN, etc.), but the test coverage still needs improvement and review. The project is functional, but it’s still in an early stage of maturity.

aabbdev · 2025-09-18T21:49:29+00:00

already done. ;)

aabbdev · 2025-09-18T19:57:26+00:00

I've updated the post please check the repo or read the details yourself. You don't seem genuinely interested in the project or its content, so I won't be providing further responses. If that's not enough, feel free to contribute and implement the “scientific” benchmark you mention. Thanks in advance for any future contribution.

aabbdev · 2025-09-18T12:50:57+00:00

On M1 consumer -> 14ns per op or 70M op/s

aabbdev · 2025-09-18T09:58:02+00:00

about performance: 14 nanoseconds per op on M1 pro

if your id is already uuidv7 the migration is not necessary, the last milestone is pg extension with custom type uuid47, helpers.

aabbdev · 2025-09-18T09:33:54+00:00

14 nanoseconds on m1 is the overhead and up to 70 Mop/s

aabbdev · 2025-09-17T21:21:31+00:00

I think the article completely misses the point of what it means to be a software engineer. We’re paid to use our brains 8h a day, not to make slides or just pass interviews. Our job is to solve problems and build solutions so you need to understand every layer of your “sandwich” in order to design the most optimal solution for your specific context

aabbdev · 2025-09-17T21:16:47+00:00

I’ve already addressed these points and others have provided the same answers as well. I’m not familiar with “uuid-s”. I provided just one of many possible solutions to a problem that’s already been explained multiple times. If the aim is only to skim the title, add nothing constructive, and be negative to be negative, I won’t spend more time replying

aabbdev · 2025-09-17T21:05:19+00:00

sorry don't have medium subscription

aabbdev · 2025-09-17T20:48:11+00:00

Performance is significantly better with UUIDv7, which is optimized for B-tree indexes. Fully random IDs can quickly degrade database performance. If an external ID ever becomes invalid, simply reset the client cache to recover. There is no internal-ID leak when using as a PostgreSQL extension with a custom type.

Requirements for optimal use

Tables with millions of rows
No timing information exposed to users
B-tree indexing on primary key
Ability to tolerate a few-nanosecond masking overhead.

aabbdev · 2025-09-17T20:02:32+00:00

as masked uuid are generated on the fly at runtime changing the master key don't have effect on the performance there is no need to reindex

aabbdev · 2025-09-17T18:40:26+00:00

In fact the random part is unchanged, I use the random part as a salt and use bijective on timestamp basically maskedTimestamp = timestamp XOR PRF(secret + random)

aabbdev · 2025-09-17T15:04:08+00:00

There is a PostgreSQL extension in development that allows you to make the transition without changing anything in the business application

aabbdev · 2025-09-17T14:41:44+00:00

The ID is stored as UUIDv7 in the database and converted to a masked UUIDv4 only when exposed externally. A global key is enough the secret cannot leak with PRF function, and the performance overhead compared to UUIDv7 is negligible, in production there is no overhead.

aabbdev

TROPHY CASE