Skip to content

Database Architecture & Security ​

This platform utilizes Supabase, which provides a managed PostgreSQL database. Because our React frontends communicate directly with the database via the Supabase client, we rely heavily on database-level security rather than a traditional middleware API layer.

This guide provides a high-level overview of the data architecture and our security philosophy.

High-Level Data Domains ​

The database is divided into a few core domains.

  1. Authentication & Profiles:
    • We use Supabase's native auth.users for secure credential management.
    • This is tied to a public users table that stores data like department and total points.
  2. Curriculum Architecture:
    • Relational tables handle the courses -> modules -> resources hierarchy.
  3. Assessment Engine:
    • Tables dedicated to quizzes and questions, including relational mappings for our multi-language translation support.
  4. Telemetry & Tracking:
    • Tables that record quiz history and generated certificates.

Row Level Security (RLS) ​

Because the User and Admin applications query the database directly from the browser, Row Level Security (RLS) is strictly enforced on all tables.

RLS acts as our bouncer. Every time a query is made, PostgreSQL checks the user's JWT (JSON Web Token) to determine if they have permission to perform that action.

The Security Model ​

  • Administrators: RLS policies look for an admin role claim. If verified, they are granted SELECT, INSERT, UPDATE, and DELETE privileges across the public schema's tables.
  • Standard Employees: Standard users operate under strictly scoped RLS policies.
    • Read-Only: They can only SELECT courses and modules that are assigned to them.
    • Scoped Mutations: They can only INSERT or UPDATE rows that belong to their specific user_id. They cannot modify or even see another employee's data.

Triggers and Edge Functions ​

To keep the frontend applications lightweight and secure, we offload complex or sensitive logic to the backend:

  • PostgreSQL Triggers: Used for automated internal data updates.
  • Edge Functions: These are used for actions that require third-party API keys or elevated server-side privileges that bypass standard RLS (e.g., generating a secure PDF certificate).

Developed for the Human Resources department.