Skuteczne ograniczenia dla userów

Chcę na podstawie dynamicznych uprawnień ograniczyć możliwości pewnych userów.
Przykład:
Dziś wprowadzam ograniczenie maksymalnie 5 recordów w tabeli X w godzinach 8-20.
Jeśli admin spróbuje dodać więcej niż 5 to program ma mu na to pozwolić, ewentualnie zanotować w audit logu, że tak było.
Jeśli user spróbuje dodać więcej niż 5 to program nie może mu na to pozwolić.

Zamiast limitu liczby recordów, może też być coś innego np brak możliwości edycji rekordu jeśli był już wcześniej edytowany albo admin może robić ile chce duplikatów a zwykły user nie, chyba że dostanie zgodę.

Dodatkowo jest podział na różne firmy. Każda tabela ma identyfikator firmy i każde żądanie do db musi mieć warunek z tym identyfikatorem.

1. Nie można użyć unique index ani innych ograniczeń z db bo to jest na stałe a tak nie może być.
2. Użycie zwykłego select for update + insert nic nie da, bo ktoś może wysłać 5 żądań na raz do api a postgresql nie zobaczy tego z poziomu transakcji i zapisze 5. W mysql za to nie ma problemu.
3. Jak to zrobić?

Ja bym to zrobił w warstwie aplikacji, a nie na bazie danych.

Jednak jak się uprzeć to można sobie stworzyć tabele user_limits gdzie będziesz miał user_id i count + trigger, który dodaje +1 dla usera przy każdym insert i sprawdza czy nie przekroczono limitu, a jak tak to zwraca błąd. Dodać trzeba też event, który będzie resetował licznik każdej nocy, albo funkcje, która będzie odpalana przez admina czy maszynę

Łatwiej i bliżej standardów branżowych będzie zrobić to na poziomie aplikacji i tak zarządzać uprawnieniami np. do wykonywania określonych operacji, czy wprowadzić rate limiting. W dodatku materiałów w sieci na temat takich rozwiazań jest od groma, rozwiązywanie tego na poziomie baz danych mogło być praktykowane z 15-20 lat temu, ale już raczej nie współcześnie.

Jeśli chodzi o użytkowników na bazie danych, nie spotkałem się z tym by użytkownicy aplikacji byli jakoś powiązani z użytkownikami bazy poza kilkunastoletnimi systemami legacy, z którymi czasem trzeba się zintegrować lub je przepisać. Jeżeli baza ma kilku użytkowników, to są to raczej konta serwisowe / administracyjne według roli, takie jak:

• użytkownik z uprawnieniami dostępu do tabel (czyli wszelkie odczyty i zapisy, wywoływanie widoków etc), bez dostępu do DDL, używany do tworzenia połączeń z BD przez aplikację
• użytkownik z uprawnieniami do modyfikacji DDL (i ewentualnie dostępu do tabel, jeśli jest potrzebne do migracji w miarę jak rozwija się schemat bazy)
• ewentualnie jacyś użytkownicy dla administratorów bazy, o ile "ludzki" dostęp jest odseparowany od tego co robią automatyczne skrypty CI/CD do migracji baz