[AVAILABLE] for
memory and supabase. Declared but unimplemented, throws at startup for postgres/sqlite.Purpose
Append-only repositories backing the Execution trust record ledger, business transactions, and (forFilePolicyRepository, in @parmana/policy)
policies.
Install
Key exports
Factory, [AVAILABLE]
PARMANA_STORAGE is the only variable read for this choice, see Deploy patterns.
Providers
| Export | Stability |
|---|---|
MemoryStorageProvider, MemoryBusinessTransactionRepository, MemoryExecutionTrustRecordRepository, MemoryPolicyRepository | [AVAILABLE]. In-process, non-persistent. Used throughout this site’s live examples. |
SupabaseStorageProvider, SupabaseBusinessTransactionRepository, SupabaseExecutionTrustRecordRepository | [AVAILABLE] (source), not independently re-verified against a live Supabase instance in this documentation pass. This repo’s committed .env defaults to this. |
Interfaces and ledger, [AVAILABLE]
| Export | Purpose |
|---|---|
StorageProvider, StorageBuilder, StorageConfiguration | The provider contract and its typed configuration |
AppendOnlyLedger, LedgerEntry, LedgerSerializer | The append-only primitive repositories are built on |
ExecutionRepository, VerificationRepository, CryptoProofRepository | Additional repository interfaces |
StorageError | Thrown on provider misconfiguration, including the retired DATABASE_PROVIDER variable, see below |
A retired variable fails loudly, not silently
An olderDATABASE_PROVIDER variable existed briefly as a second, disconnected path to the
same setting PARMANA_STORAGE now controls. If it’s present in the environment, config
loading fails at startup naming PARMANA_STORAGE as the replacement, rather than silently
ignoring it or picking one arbitrarily.
Minimal example
Next
Deploy patterns
Choosing a storage provider as part of a full deployment.
Execution trust records
What actually gets stored, and what’s append-only versus signed.