Pillar 03
Storage
Data is co-located with the community that owns it. Sharded PostgreSQL for relational data, MinIO for objects and files, and encrypted blobs for sensitive content — all under member control, none in a shared cloud.
Design philosophy
Most platforms store all user data in a single multi-tenant database managed by the platform provider. Members have no practical ability to inspect, export, or delete their data independently of other tenants. irl.coop takes the opposite approach: each cooperative shard owns its own storage layer.
Relational data — Citus (PostgreSQL)
Member records, governance proposals, event logs, and structured cooperative data are stored in PostgreSQL with the Citus sharding extension. Citus allows the database to be distributed across multiple physical nodes while maintaining full SQL compatibility.
Sharding model
Data is sharded by cooperative ID. All data belonging to a specific cooperative shard lives on nodes that the shard operator controls. When a member queries their cooperative's data, the query is routed to their shard's nodes — not to a shared pool.
NocoDB interface
NocoDB provides a spreadsheet-like interface to the PostgreSQL database for non-technical members. Coordinators can use NocoDB to manage member records, event registrations, and resource inventories without writing SQL.
Object storage — MinIO
Files, images, documents, and media are stored in MinIO, an S3-compatible object store that runs on the cooperative's own hardware. MinIO provides:
- Versioning — every file version is retained and accessible
- Bucket policies — per-resource access control aligned with the authorization layer
- Encryption at rest — all objects are encrypted with keys held by the cooperative
- Replication — objects can be replicated across multiple nodes for redundancy
Encrypted blobs
Sensitive content (private messages, financial records, health data) is stored as encrypted blobs. The encryption keys are managed by the Lit Protocol MPC network — they are split across multiple independent nodes and can only be reconstructed when the authorization conditions are met. This means the storage node operator cannot read the content even if they have physical access to the disk.
Data residency
Data residency is enforced by the shard architecture. Cooperatives that need data to remain in a specific geographic region simply operate their storage nodes in that region. There is no shared storage pool that would cause cross-border data flows.
Member data rights
- Export — members can export all their data in standard formats at any time
- Deletion — members can request deletion; the platform executes a verifiable deletion workflow
- Portability — exported data can be imported into another irl.coop shard or a compatible federated system
- Auditability — access logs for member data are available to the member
Backup and recovery
Each shard is responsible for its own backup strategy. The platform provides tooling for:
- Automated daily snapshots of the PostgreSQL database
- MinIO bucket replication to an offsite node
- Point-in-time recovery for the last 30 days of database state