6e8f0db6c0
- Add dialogue prompt file writing for audit/debugging - Update README install instructions - Add new RFCs (0053, 0055-0059, 0062) - Add recorded dialogues and expert pools - Add ADR 0018 dynamodb-portable-schema - Update TODO with hook configuration notes Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
1.9 KiB
[PERSPECTIVE P01: DynamoDB's serverless-native deployment model is the real parity advantage RFC 0058 provides] The debate has fixated on query ergonomics and local-prod parity, but nobody has addressed deployment topology. DynamoDB is connectionless, scales to zero, requires no connection pooling, and works identically from Lambda, Fargate, or edge runtimes with sub-10ms cold paths. PostgreSQL -- even Neon or Turso -- imposes connection management (pooling, idle timeouts, max-connections-per-Lambda), regional affinity constraints, and a fundamentally different cold-start profile in serverless contexts. RFC 0058's client-side encryption model (encrypt in the application, store opaque blobs) is uniquely suited to serverless: the compute layer is stateless and the storage layer is dumb. A hybrid that routes some queries to PostgreSQL forfeits this property and locks the architecture into connection-aware runtimes, which is a deployment constraint masquerading as a data modeling choice.
[PERSPECTIVE P02: RFC 0053's trait abstraction already solves the escape hatch without committing to a hybrid today]
RFC 0053 defines DialogueStore and Store<T> traits with backend-agnostic signatures. If the DynamoDB graph-traversal pain proves real in production, a PostgreSQL implementation can be swapped in behind the same trait boundary without changing application code, without hybrid routing, and without the operational overhead of running two databases simultaneously. The question is not "DynamoDB vs. hybrid now" but "DynamoDB now with a clean trait boundary that makes a future swap trivial."
[TENSION T01: Serverless deployment constraints vs. relational query expressiveness] The panel has not established whether the target deployment environment is serverless (Lambda/edge, where DynamoDB excels) or containerized (ECS/EKS, where PostgreSQL is equally viable), and this architectural context changes which database's weaknesses actually matter.