The job was to turn product, privacy, consent, and reporting requirements into data structures that the rest of the system could rely on.

Context

SaliHub was developing a multi-tenant preventive-health platform with data arriving from people, devices, and application workflows. That combination makes ordinary schema choices consequential: tenant boundaries, source identity, consent state, and audit history have to survive as the product changes.

My role covered the PostgreSQL data architecture and the implementation work needed to evolve it safely. This case study focuses on that engineering contribution.

Engineering scope

I designed and evolved relational structures for core product data, and translated changing requirements into schema migrations and technical documentation. The work included access-control policies, audit logging, consent-related data, and reporting structures.

I also contributed database health checks and test scaffolding. For health signals arriving from multiple devices, I worked on source-aware deduplication so that repeated observations could be reconciled without erasing provenance.

DATA BOUNDARY MAP / 01One health observation, five contexts to preserve.The data model carries ownership, permission, provenance, and history before information becomes useful for reporting.
  1. 01ObservationPerson, device, or application workflow
  2. 02IdentityTenant and source context
  3. 03PermissionAccess and consent state
  4. 04HistoryAuditable change record
  5. 05UseProduct and reporting structures
RELATIONAL COREPostgreSQL data architectureSchemas, migrations, access rules, health checks, and test scaffolding evolve together.
FOUNDATIONS / ASource-aware deduplicationReconcile repeated signals without erasing provenance.
FOUNDATIONS / BExplicit tenant ownershipKeep boundaries visible and testable in the data model.
FOUNDATIONS / CConsistent audit vocabularyRecord actor, record, action, and time for later questions.

Decisions that mattered

Tenant boundaries belong in the data model

Multi-tenancy is not just an application filter. The schema and access rules have to make ownership explicit, keep cross-tenant reads difficult, and remain testable as new workflows appear.

Auditability is a data product

An audit trail must record events in a form that can answer concrete questions later. That means defining actors, affected records, actions, and timestamps consistently, not merely turning on logs.

Deduplication must preserve source context

Two measurements that look the same may be separate observations; two that look different may describe the same event. The approach therefore used source identity and domain context rather than treating equality as a universal rule.

Takeaway

The durable lesson was that data architecture is the negotiated boundary between product behavior and system truth. Good schemas do more than store records: they make ownership, history, and failure modes inspectable.