Hub storage backends

The Hub is storage-agnostic. Claresia ships four backend implementations behind the same Hub schema (cc-050). Pick based on deployment mode, scale, and your customer’s data-stack alignment.

At-a-glance

Backend	Mode A	Mode B	Mode C	Best for
Postgres (RDS / Azure Database / Cloud SQL)	✅ default	✅ default	✅ default	Most customers; SQL-comfortable
SharePoint (M365 lists + SPO files)	—	—	✅	Microsoft-native customers without a Postgres footprint
Snowflake (managed warehouse)	—	—	✅	Customers whose data team lives in Snowflake; analytics-first
In-Memory (test / demo)	dev only	dev only	dev only	Local dev, integration tests, demo dashboards

Postgres

The default backend across all three deployment modes.

Mode	Postgres flavour	Tenant isolation
A	Shared AWS RDS Aurora cluster	Row-Level Security keyed on app.tenant_id
B	Dedicated Aurora Serverless v2 per tenant	Per-tenant CMEK in customer-named KMS
C	Customer-managed (RDS / Azure Database / Cloud SQL)	Customer-owned everything

Schema

The schema bootstrap script lives at Claresia - Roadmap/cc-050-intelligence-hub/python/claresia_hub/adapters/postgres_schema.sql. Six tables (outputs, decisions, governance_events, artifacts, employee_profiles, telemetry_events) + tenant-scoped indexes + RLS policies.

Performance characteristics

• 50k records/s sustained write per tenant on db.r6g.2xlarge
• p95 read by record_id: <5 ms
• p95 read by (tenant_id, skill_id, created_at desc) filtered query: <15 ms
• Provenance hash verification adds <1 ms

Backup + restore

• Automated daily snapshots, 35-day retention (Mode A/B)
• Point-in-time-recovery within 7 days (Mode A) / 35 days (Mode B)
• Mode C: customer-controlled (Terraform module ships sensible defaults)

SharePoint (Mode C only)

For customers fully invested in M365 who want the Hub data plane to live in SharePoint Online alongside their existing document estate.

Topology

• Each Hub record type maps to a SharePoint list in a per-tenant Site Collection (https://yourtenant.sharepoint.com/sites/claresia-dainese)
• artifact records’ bodies live as files in the corresponding Document Library
• Per-tenant SharePoint permissions = your existing Microsoft 365 ACLs
• Provenance hashes computed identically; stored in a provenance_hash column per list

When to choose SharePoint

• Customer’s IT preference is “everything in M365”
• No DBA team to manage Postgres
• Compliance team comfortable auditing in M365 Purview / Microsoft 365 audit log
• Snowflake / data warehouse access is not a top-tier requirement

Performance characteristics

• Slower than Postgres — typical p95 read: 100–300 ms
• Sustained write: ~10 records/s per list (SharePoint API throttling applies)
• Recommend Postgres if your skill-invocation volume exceeds 10k/day

Snowflake (Mode C only)

For customers whose data team standardized on Snowflake and want the Hub to be queryable alongside their other warehouse data.

Topology

• Per-tenant Snowflake database (CLARESIA_DAINESE_HUB)
• Six tables (one per record type)
• Snowflake streams + tasks propagate writes to your downstream models
• Customer-owned warehouse compute (your warehouse, your bill)

When to choose Snowflake

• Customer’s analytics team is Snowflake-native
• Want to join Hub data with your CRM, ERP, ticketing data in the warehouse
• High-volume telemetry analytics (fn_telemetry_event joined to revenue facts)

Performance characteristics

• Optimized for analytical queries (cost-per-skill rollups, archetype L1→L2 progression, manager dashboards)
• Lookup-by-record_id: ~50–100 ms (slower than Postgres)
• Write: micro-batch via Snowpipe Streaming, ~2s end-to-end latency
• Recommend dual-write Postgres + Snowflake if you need both OLTP record-by-id and OLAP rollups

In-Memory (test / demo only)

A pure in-process Python / TypeScript implementation of the Hub interface. Used by:

• Unit tests (cc-050 conformance suite)
• Integration tests for downstream Functions
• Demo dashboards that don’t need persistence

Never use in production — restart loses all data, no backup, no concurrency beyond a single process.

How the choice flows through the architecture

Customer signs Mode A or B
    ↓
Onboarding Portal Step 7 → Postgres provisioned automatically
    ↓
Done. Customer never thinks about backend.

Customer signs Mode C
    ↓
Pre-flight call: pick backend (Postgres / SharePoint / Snowflake)
    ↓
Apply Claresia's Terraform module for the chosen backend
    ↓
Run the schema migration
    ↓
Paste the customer endpoint into Onboarding Portal Step 7

See Mode C deploy guide for the full BYOC flow.

Switching backends

Switching between backends is a migration, not a config change. Hub records are physically copied with provenance preserved. Typical migration windows:

From	To	Wall-clock	Downtime
Postgres → Postgres (region change)	4–8 hours	None (online)
Postgres → SharePoint	12–24 hours	Read-only window during cutover
Postgres → Snowflake	8–16 hours	None (dual-write during cut-over)
SharePoint → Postgres	24–48 hours (SP throttling)	Read-only window during cutover

Talk to your CSM in your #claresia-{tenant} channel before switching.