Skip to main content
Parmana separates what the Runtime needs from storage (an interface, defined in shared) from how that need is actually met (an adapter, implemented in storage). 
Application
        |
        v
Repository Interface
        |
        v
Storage Adapter

​
Supported and planned adapters

  • In-memory (used for tests and local development)
  • PostgreSQL
  • Supabase
  • Other cloud-native databases
  • Custom enterprise adapters
The Runtime never depends on a concrete storage technology — only on the repository contracts defined in shared. This is part of why Parmana describes itself as storage agnostic: swapping the in-memory adapter for a PostgreSQL-backed one is a change confined to the storage package.

​
Why this matters for trust

Because Execution Trust Records are append-only and immutable (see Security Model), the repository layer’s job is narrower than in most systems: it never needs to support updates to historical rows, only inserts and reads. This significantly reduces the surface area for storage-layer bugs to corrupt trust evidence.