Security / platform
Database design for a full-stack e-commerce platform
The relational architecture behind authentication, row-level security, and multi-concern data access in a production Supabase PostgreSQL environment.
Technical narrative
This is where the archive goes deeper than the homepage: architecture choices, operating constraints, and the decisions that make the product maintainable over time.
A production commerce platform has more than one kind of user touching the data. Customers browse and purchase. The owner manages inventory, promotions, and analytics. The system itself needs to enforce boundaries between those roles without relying on application-level checks alone.
The database is structured around clear domain boundaries: storefront data, operational data, and system data. Tables are normalized where consistency matters and denormalized where query performance matters. Foreign keys and indexes are placed according to application query patterns.
Supabase RLS policies control who can read and write what. Public-facing tables allow anonymous reads but restrict writes to authenticated admin users. Operational tables are scoped to the owning customer or admin role. That keeps the security model close to the data instead of scattering it across route handlers.
Authentication uses Supabase Auth with role-based access layered on top. The admin dashboard and the customer-facing storefront share the same database but see different slices of it, controlled by RLS and role checks. That architecture keeps future endpoints safer by default.