Suggestion: Store timestamp of alias deletion in the global trash

[vlakoff]

SimpleLogin uses a "global trash" mechanism to prevent deleted aliases from being reassigned. It serves its purpose well, but I'm concerned about the indefinite growth of this database. Over time, this could impact storage size and potentially degrade lookup performance.

While this ever‑growing dataset may not pose a practical issue today, it's generally good practice to allow for the purging of very old data—say, entries that are decades old. Currently, the global trash database stores only the aliases, without any metadata.

I suggest recording the timestamp of when each alias is added to the global trash. This would provide a mechanism to remove stale data (e.g., entries older than 20–30 years) if the need ever arises. The motivation here is largely theoretical, but it's a forward‑looking improvement.

The implementation cost is minimal: a single 64‑bit integer added to each new row. From there, it opens up new possibilities for data management. And if ever desired, the column could still be removed later.

Some related links:

• Global trash #168
• Can others use my email alias? #1043

Only vaguely related, but possibly of interest — a Wikipedia infrastructure issue:

• https://phabricator.wikimedia.org/T406724

[nguyenkims]

Thanks for the suggestion.

I suggest recording the timestamp of when each alias is added to the global trash

This global trash table has the created_at column which indicates when a row is added.

Currently we are very far from the postgres limit on the number of rows (postgres can store billion of rows). We have some monitoring on the database that alarm us when some tables are getting too big and we can then prune them if needed.

[vlakoff]

Thanks for the reply!

Indeed, PostgreSQL can handle billions of rows. For reference: PostgreSQL Limits.

If a created_at column is already present in the global trash table, then that's perfect — it covers exactly what I had in mind. And the fact that there's monitoring in place to alert when tables grow too large makes the situation even better.

The amount of data will likely grow faster and faster over time, but hardware capabilities tend to improve even more rapidly — at least for now. So there shouldn't be any real issue. Again, it's just my obsessive side being bothered by the idea of the data being "evergrowing", for instance if I play around and delete aliases I haven't even used.

[vlakoff]

While database tables can handle billions of rows, it's worth noting that Proton Mail has over 100 million users — so having safeguards like monitoring, and potentially table splitting or pruning, remains essential.

That said, no action seems needed in the short or even medium term, so I'm closing the ticket.