Files
Baradb/docs/superpowers/specs/2026-07-30-production-ga-design.md
T
dimgigov 09f462f467
CI / test (push) Has been cancelled
CI / verify (push) Has been cancelled
Clients CI / build-server (push) Has been cancelled
Clients CI / test-python (push) Has been cancelled
Clients CI / test-javascript (push) Has been cancelled
Clients CI / test-nim (push) Has been cancelled
Clients CI / test-rust (push) Has been cancelled
release: v1.2.0 Production GA (single-node)
- known-limitations, deployment runbook, release checklist
- prod compose requires JWT secret; BARADB_ENV=production fail-closed
- scripts/backup-restore-drill.sh (backup → wipe → restore → verify)
- version bump 1.2.0 (nimble, Dockerfile, health, CHANGELOG dated)
2026-07-30 21:52:21 +03:00

2.7 KiB

Production GA (v1.2.0) — Design / cut line

Date: 2026-07-30
Status: Done (v1.2.0 GA shipped) — plan
docs/superpowers/plans/2026-07-30-production-ga.md.

Problem

BaraDB has substantial features (storage hardening, search, engine persistence, Raft cluster path) but “production” never arrives because work stays on the feature treadmill without a release + ops cut line.

Goal

Ship v1.2.0 Production GA for a defined scope:

Single-node (or single primary) BaraDB suitable for real applications, with documented limits, tested backup/restore, secure-by-default prod compose, tagged release, and a one-page runbook.

Raft multi-node remains supported experimental / ops-documented, not the GA reliability target for v1.2.0.

Non-goals (v1.2.0)

  • Multi-database Raft
  • InstallSnapshot full SM dump / automatic cold-node catch-up beyond AppendEntries
  • Membership changes (add/remove voters)
  • Raft TLS
  • Replacing Postgres HA marketing claims
  • New major SQL/AI features

Success definition

# Criterion
1 Git tag v1.2.0; baradadb.nimble + README version 1.2.0
2 CHANGELOG.md section [1.2.0] dated (not Unreleased)
3 docker-compose.prod.yml: auth required (or fails closed if secret missing)
4 Scripted backup → wipe data → restore → query succeeds
5 nimble test green on release-shaped build (or documented subset + binary e2e)
6 Runbook: start/stop/backup/restore/logs/ports in docs/en/deployment.md
7 Known limitations page (single-node GA vs raft experimental)
8 Optional: one smoke app path (nimforum or ormin) on release binary

Threat model (honest)

In scope for GA: process crash, disk full (document), operator restore, unauthenticated internet (mitigated by auth-on in prod).

Out of scope for GA: multi-region, zero-downtime upgrades, perfect follower-read consistency, multi-tenant SaaS isolation audit.

Architecture of the release

[build release binary + image]
        │
        ▼
[prod compose: auth + data volume + healthcheck]
        │
        ▼
[backup tool / HTTP backup] ──► offsite copy
        │
        ▼
[restore drill script] proves recoverability
        │
        ▼
[tag + docs + known-limitations]

Follow-on (v1.3.0 — not this plan)

  • Raft cluster “supported” tier: failover under write load, CI e2e, cold peer story
  • Multi-DB raft or explicit product refusal
  • InstallSnapshot / membership

References

  • Raft status: docs/superpowers/specs/2026-07-30-raft-cluster-status.md
  • Ops: docs/en/distributed.md, docs/en/backup.md, docs/en/deployment.md
  • Compose: docker-compose.prod.yml