EVIDENCE & VALIDATION

See what each Halo claim establishes—and what it does not.

Material statements are paired with their manual source, practical meaning, boundary, and workload question.

Material product evidence

Documented statement: Halo is described as an openHalo-based, general-purpose unified database. Halo 1.0.16 is listed as the second LTS release, published in June 2024.
Manual source: Chapters 1–2
What it does not prove: This does not confirm current packaging, certification, regional service, or an English legal company identity.
What to validate: Confirm the exact build, package, platform, and support scope intended for deployment.

Documented statement: One instance can run Oracle, MySQL, and PostgreSQL modes concurrently; E5 spans protocol, parsing/semantics, optimization, and execution.
Manual source: Chapter 7; Chapters 8–10
What it does not prove: This does not establish complete equivalence or unchanged behavior for every application.
What to validate: Test the data types, functions, objects, procedural behavior, drivers, transactions, and errors the application uses.

Documented statement: The manual reports at least 95% lower Oracle-related application code changes in migration practice.
Manual source: Chapter 1; Oracle overview
What it does not prove: This is not a universal percentage, zero-change promise, hour-scale promise, or performance guarantee.
What to validate: Measure required changes against a representative dependency inventory and PoC record.

Documented statement: The manual documents physical/logical replication and backup; incremental physical modes; validation; and PITR to time, LSN, transaction ID, restore point, or timeline.
Manual source: Chapters 11–15; Appendix B
What it does not prove: Mechanisms alone do not establish an SLA, RPO, or RTO. Sync and async choices differ.
What to validate: Exercise the intended topology, failure, reconnect, data state, and operator procedure.

Documented statement: DLB, TWR, HSM, and HDS address read distribution, write forwarding, shared storage, and sharded placement as distinct components.
Manual source: Chapters 16–19
What it does not prove: The source does not establish universal active-active behavior, linear scale, online resharding, distributed transactions, or topology-independent durability.
What to validate: Select the component and topology, then test routing, failure, consistency, placement, lifecycle, and operations.

Documented statement: HWR snapshots and interval reports, 139 catalog/view objects, and 45 extension modules provide documented paths for visibility and diagnostics.
Manual source: Chapter 21; Appendices C–D
What it does not prove: Counts do not mean every module is installed or enabled by default; HWR has dependencies and collection behavior.
What to validate: Confirm installed modules, permissions, collection settings, retention, overhead, and workflow.

Documented statement: The installation material lists multiple x86, ARM, MIPS, and Alpha families and several Linux distributions plus FreeBSD.
Manual source: Chapter 3
What it does not prove: A manual list is not a current certification or support matrix.
What to validate: Confirm processor, operating-system version, package, and support status before procurement.