Files
hub/docs/decisions/ADR-001-jsonb-data-columns-vs-individual-columns.md
glm-5.1 2b63cda1c7 Setup repo: migrate architecture specs, code stubs, and tasks from alkhub_ts
Copy architecture docs, ADRs, storage domain specs, research, reviews,
and 56 storage architecture tasks from the alkhub_ts monorepo. Adapt for
standalone @alkdev/hub repo structure (src/ not packages/hub/).

Sanitize all sensitive information:
- Replace private IPs (10.0.0.1) with localhost defaults
- Remove internal server hostnames (dev1, ns528096)
- Replace /workspace/ private paths with npm package references
- Remove hardcoded credentials from examples
- Rewrite infrastructure.md without private network details

Add Deno project scaffolding: deno.json (pinned deps), .gitignore,
AGENTS.md, entry point. Migrate existing code stubs (crypto, config
types, logger) with updated import paths.
2026-05-25 10:56:32 +00:00

812 B

ADR-001: JSONB data columns vs individual columns

  • Status: Accepted
  • Date: 2026-04-19
  • Deciders: alkdev

Context

Opencode stores message and part content as JSON blobs in a data column. AI SDK UIMessage uses inline parts. Need format that works for both query flexibility and streaming.

Decision

Use separate structured columns for high-query, high-filter fields (role, status, type) and JSONB data columns for rich, type-discriminated content. Follows opencode pattern.

Consequences

JSONB content is opaque to SQL queries on individual fields. If we need to query inside data, add generated columns or GIN indexes. Flexibility outweighs the query limitation for now. Positive: clean separation between queryable and flexible data, consistent with proven opencode pattern.