Specifications

Engineering specifications and design documents for Drizzle. These docs describe in-progress and planned work in detail sufficient for a team of contributors (or subagents) to execute against.

• Drizzle Revival (2026)
  • Status and next
  • Context and goals
  • Foundational principles
  • Phase map
  • Dead-dep policy
  • Phase 0 — Tests in container, Zuul wiring, spec landed
  • Phase 1 — Strip dead platforms, delete dead-dep plugins
  • Phase 2 — Performance baseline harness
  • Phase 3 — Container hygiene and Phase 0 follow-ups
  • Phases 4–10 — LTS bump template
  • Phase 11 — Pandora slim-down to m4/drizzle.m4
  • Phase 12 — Constant-fold the hardcoded defines into the source
  • Phase 13 — Plugin enable-by-default sweep
  • Phase 14 — Sphinx-only docs
  • CI strategy — Zuul on OpenDev
  • Appendix — Multi-arch hazards
  • Appendix — C++ and threading correctness debt
  • Appendix — Investigation backlog
  • Future work
• Performance tracking
  • Introduction
  • What we measure
  • Architecture
  • Authentication and the upload flow
  • Regression gating
  • Where the work lives
  • Follow-ups
  • Alternatives
• Iceberg Storage Engine: Design
  • Scope and thesis
  • Library and catalog landscape (as of July 2026)
  • Build and dependency policy: container-first, no detection
  • Identifier model
  • Metadata: the catalog is the source of truth
  • Type mapping
  • Read path: Planner / Executor split
  • Snapshot pinning: per transaction
  • Write path: buffer until commit
  • DDL
  • The core gap: predicate pushdown (phase 3)
  • Observability and time travel (phase 4)
  • Component layout
  • Ownership and style
  • Task sequence
  • Verification requirements (all tasks)
• SlateDB Storage Engine: Design
  • Scope and thesis
  • Why SlateDB specifically
  • Library landscape (as of July 2026)
  • The FFI shim: libslatedb_capi
  • Build and dependency policy: container-first, and the composition note
  • Data model: one database, prefixed keyspaces
  • Key and value encoding
  • Transactions and isolation
  • Durability, latency, and cost
  • DROP TABLE reclamation
  • Operational model
  • Refused in v1 (all loud, all specific)
  • Known limits, stated not hidden
  • Implementation plan

Proposed Implementations

• Performance tracking — implementation plan
  • Reference facts the prompts rely on
  • Dependency graph
  • Patch 1 — drizzle/drizzle-test: measured-server images + build job
  • Patch 2 — drizzle/drizzle-test: sysbench load-gen image + build job
  • Patch 3 — drizzle/drizzle-test: runner + compose + perf job (artifact only)
  • Patch 4 — drizzle/drizzle: remove the stranded perf harness
  • Patch 5 — drizzle/perf-tracking: results service + dogfood integration job
  • Patch 6 — drizzle/drizzle-test: close the loop (gating + upload)
  • Patch 7 — drizzle/drizzle: trigger perf on server changes
  • Open items (none blocking)
• Iceberg storage engine — implementation plan
  • Task 1: iceberg-cpp spike and CI fixtures — container-first
  • Task 2: Plugin skeleton and build integration
  • Task 3: Catalog-backed metadata
  • Task 4: Read path — planner, executor, cursor, pinning
  • Task 5: Transactional buffered append
  • Task 6: DDL — CREATE with transforms, DROP without purge, RENAME
  • Task 7: Predicate pushdown — a core seam, then pruning
  • Task 8: Dictionary tables and time travel
• SlateDB storage engine — implementation plan
  • Task 1: slatedb-capi shim, container image, and spike
  • Task 2: the memcomparable key codec and row value codec
  • Task 3: plugin skeleton, metadata, and DDL
  • Task 4: cursor read and write paths, autocommit, primary key only
  • Task 5: multi-statement transactions
  • Task 6: secondary indexes, unique and non-unique
  • Task 7: DROP reclamation, fencing behavior, and operational surface

Associated Notes

These aren’t specs per-se, they’re just collections of notes that might feed into a spec.

• Replication Notes
  • Context
  • What exists
  • Current caveat
  • External queues
  • Terminology
  • Storage-engine note