Designed a PostgreSQL function‑first data layer across the platform's domain schemas (identity, organization, review, message, notification and more), exposing all data access through stored functions.

Situation. Business logic has a way of leaking. A bit ends up in the API, a bit in some SQL a handler runs inline, and before long the same rule is written two or three slightly different ways and there’s nowhere you can point to and say “this is what the system does with its data.” That’s how bugs and security holes get in.

Task. The goal was one home for all of it: every read and write going through the database, the API a thin adapter that doesn’t know the business rules, and the whole thing lockable down tight.

Action. The data layer is function‑first. The schema is split by domain — identity, organization, review, message, notification, and a couple of dozen more — and every operation the app can do is a PostgreSQL function it calls; there’s no direct table access from Go at all. Then the database enforces it. The role the API logs in as, mariner, has EXECUTE on the app functions and USAGE on the schemas and nothing else — no SELECT, no INSERT, no way to touch a table directly. The functions run SECURITY DEFINER, owned by a separate non‑login function_owner role with a pinned search_path, and the superuser account stays reserved for migrations and cron, well away from the running app.

Result. The logic lives in one place you can actually audit, the API stays thin and boring in the good way, and the access boundary is enforced by Postgres itself rather than by everyone remembering the rules. If the API were somehow compromised, it still couldn’t do anything the functions don’t allow.