One additional gotcha here that we just ran into – an unexpected side effect of: CREATE UNLOGGED TABLE request_log ( id BIGINT GENERATED BY DEFAULT AS IDENTITY, ip inet NOT NULL, timestamp timestamptz DEFAULT NOW() ); was that while the request_log table was unlogged, the sequence created by id (request_log_id_seq) was logged. this led to us running into a bug when we attempted to update our Postgres: https://postgrespro.com/list/thread-id/2707900 we were able to resolve (courtesy of Supabase infra team identifying the issue + Claude identifying the fix!) by altering the table to use an unlogged sequence instead.

This has been a huge help as I ran into the exact same series of issues – thank you! Since you use chrome.storage, I would just flag this concept of a storage adapter was very helpful for managing that under the hood: https://stackoverflow.com/questions/76572760/auth-in-chrome-extension-with-supabase/77161107#77161107

This is great – we just implemented rate limiting pretty much exactly as described here. Only small gotcha was the check_rate_limit() function – we forgot that we use HEAD requests to validate username availability during signup, important to exclude those in addition to GET!