Schema explorer
A real database, running inside your browser tab, that you can type questions into.
Postgres compiled to WebAssembly. Multi-tenant schema with live row-level isolation you can toggle.
Same query, same database. Switch tenants and the rows change; bypass the policies and you see everyone's.
- tenants
The isolation boundary. Every other table hangs off this one.
id pk · name · plan · created_at
- users→ tenants
Per-tenant accounts. Email is unique inside a tenant, not globally.
id pk · tenant_id fk · email · role
- sites→ tenants
Physical locations, coded per tenant.
id pk · tenant_id fk · code · region
- racks→ tenants, sites
Cabinets within a site.
id pk · tenant_id fk · site_id fk · label · units
- assets→ tenants, racks
The machines themselves. Hostname is unique per tenant.
id pk · tenant_id fk · rack_id fk · hostname · status · cpu_pct
- alerts→ tenants, assets
Raised against an asset; open ones carry a partial index.
id pk · tenant_id fk · asset_id fk · severity · resolved_at
- maintenance_windows→ tenants, sites
Scheduled downtime per site, with an ordering constraint.
id pk · tenant_id fk · site_id fk · starts_at · ends_at
- audit_log→ tenants, users
Append-only trail, indexed newest-first per tenant.
id pk · tenant_id fk · actor_id fk · action · at
run a query
“Architected full-stack platforms using Next.js, TypeScript, Prisma and PostgreSQL, designing a 50+ entity relational data model with indexing, constraints, and multi-tenant access patterns.”Dell Technologies — Internal Full-Stack Platforms
How it works
There is a real Postgres in this tab. PGlite is the server compiled to WebAssembly, so the schema, the planner and the policies are the actual ones — EXPLAIN ANALYZE works, and the numbers it prints are real.
Isolation is enforced by the database, not by remembering to write a filter. Each table carries a policy that compares its tenant_id against a session variable, so a query that forgets its tenant returns nothing rather than everything — the safe direction to fail.
The bypass switch is not a simulation. Superusers ignore row-level security entirely, so visitor queries normally run as an unprivileged role with the tenant set on the session; flipping the switch runs the identical SQL as the superuser instead, and rows from other tenants appear. That is the failure mode the policies exist to prevent, shown rather than described.
Every index leads with tenant_id, because every hot path filters by it first. Open alerts get a partial index rather than a whole one, since resolved alerts are the majority and nobody queries them.