Cloud Architecture Options for CATz Deployments

Every CATz engagement runs somewhere. This article is the decision framework for where.

The CATz stack has specific infrastructure requirements that interact differently with each cloud platform's pricing, managed service availability, and operational posture. Getting this decision right during Scaffold is load-bearing: the wrong choice surfaces at scale, not at proof of concept.

The CATz Stack — Infrastructure Requirements

The Canary Retail platform that anchors every CATz engagement depends on five infrastructure primitives:

Platform Comparison

PostgreSQL 17 + pgvector

The canonical choice for managed PostgreSQL is a function of whether pgvector is available and at what version cost. pgvector 0.7+ is required for 1024-dimension index support (half-vector compression and HNSW indexes).

Verdict. AWS RDS PostgreSQL is the most operationally straightforward choice if the rest of the stack is AWS-native. Azure Flexible Server is price-competitive and the pgvector support is solid. GCP Cloud SQL is capable but the pricing model is less transparent at small scale.

Valkey / Redis

Valkey is the Redis-compatible open-source fork. Managed offerings universally market themselves as "Redis compatible" — the critical check is Valkey Stream support, which drives the TSP ingestion pipeline.

Verdict. AWS ElastiCache is the lowest-cost entry and has the deepest operational tooling. For self-managed deployments (including GrowDirect-managed infrastructure where the retailer has control), Valkey can run in-container alongside the Flask app on a single EC2 instance — eliminating the managed service cost entirely until scale demands it.

Ollama / GPU Inference (Embedding Workloads)

The qwen3-embedding:8b model running under Ollama generates 1024-dimension vectors for the memory bus. At SMB retailer scale (100–5,000 chunks/day being embedded), CPU-only inference is viable. GPU becomes relevant when embedding workloads exceed ~50,000 chunks/day — which corresponds roughly to a 100+ store rollout.

Practical recommendation. At SMB scale, run Ollama in a container on the application server (CPU-only). The embedding workload for a 5–15 store retailer is well within CPU capacity — qwen3-embedding:8b requires ~8GB RAM at full precision but runs acceptably on a 4GB instance with quantization. Separate GPU infrastructure only when the embedding queue consistently lags or when the retailer's vault is growing faster than ~10,000 new chunks/month.

Object Storage

All three platforms offer S3-compatible object storage. The differentiating factor at CATz scale is egress cost and the cross-region transfer story when tenants are in one region and reporting consumers are in another.

At CATz scale (see method/data-economics for worked examples), storage differences are in the noise. Egress becomes the relevant cost when exporting transaction history to external analytics consumers or when migrating tenants. GCP is marginally cheaper on egress; AWS is the default because the rest of the stack already runs there.

Managed Container Options

The CATz Flask stack runs in containers (Flask 3 + Gunicorn). Managed container platforms differ on cold-start latency, persistent volume support, and operational overhead for a workload that is persistent-process (not bursty/serverless).

Verdict. For small deployments (single tenant, low transaction volume), EC2 with Docker Compose is the simplest and cheapest option — no managed container service overhead. ECS on EC2 becomes attractive when operating 10+ tenants and the operational leverage of managed scheduling is worth the overhead.

Recommended Posture

Current Production (GrowDirect-Managed Infrastructure)

GrowDirect's production stack runs on EC2 t3.micro (AWS us-east-1) under the growdirect.app domain. This is the GrowDirect-managed posture: one EC2 instance runs the shared Docker Compose stack (PostgreSQL, Valkey, Ollama, Flask apps), with per-tenant database isolation on a single PostgreSQL host.

This posture holds when: - Total tenant count ≤ 10 (connection pooling and shared PostgreSQL remain manageable) - Aggregate transaction volume ≤ ~2,000 transactions/hour (EC2 t3.micro CPU stays below 70% sustained) - No tenant has compliance requirements (PCI DSS, SOC 2) that demand dedicated infrastructure - The VAR or MSP model (Rapid POS, for example) doesn't require tenant-specific cloud credentials

When it breaks: - Any tenant requires dedicated cloud infrastructure (their own AWS account, their own RDS instance) - Aggregate load exceeds t3.micro capacity — next tier is t3.small (~$15/month) or t3.medium (~$30/month) - A third-party audit requires infrastructure isolation documentation that shared Docker Compose can't provide - Sub-tenant MSP model: Rapid POS deploys Canary to their merchant base, and each merchant needs an isolated environment

Upgrade Path at Scale

These are estimates. Actual costs vary materially based on transaction volume, data retention policy, and whether GPU inference is required.

Tenant Isolation Model

The current production pattern is per-tenant PostgreSQL databases on a shared host. This is the lowest-cost isolation mechanism and the right starting posture for a GrowDirect-managed deployment.

Per-Tenant Database Pattern (Current)

Each tenant gets: - Dedicated PostgreSQL database (canary_<tenant_id>, cove_<tenant_id>) - Database-level user with no cross-tenant privileges - Valkey namespace isolation via key prefix convention (<tenant_id>:*) - Application-layer tenant context enforcement (Flask middleware)

Cost of 50 isolated tenant databases on each platform:

Recommended. For GrowDirect-managed deployments at 10–50 tenants: shared PostgreSQL host (RDS db.t3.small or equivalent), per-tenant databases. Aurora Serverless v2 is the upgrade path when workload patterns are spiky — the ACU auto-scaling eliminates over-provisioning. Isolated RDS instances per tenant are only warranted when a specific tenant's compliance or SLA requirement demands it.

Decision Summary

Related

• method/catz-method-detail — CDF phases and workstreams (WS1 — Architecture & Infra)
• method/data-economics — data egress economics, storage costs, own-your-data argument
• method/it-architecture-options — Phase II architecture evaluation framework