Heterogeneous workload compatibility
Oracle, MySQL, and native PostgreSQL paths in one database platform.
ABOUT HALO
Built from a migration problem. Evolved into a unified database.
Halo’s documented history began in 2012 with the challenge of moving an Oracle application while reducing migration risk and cost. Compatibility remained part of the product architecture as Halo expanded into a multimode enterprise database.
Product provenance
2012 — The starting problem
The founding team began database work around an Oracle application migration; the first recorded compatibility effort focused on SYSDATE behavior.
2021 — First V1 release
Halo 1.0.13 extended Oracle-oriented procedural compatibility.
2022 — First LTS
Halo 1.0.14 introduced E5, GB18030 support, PL/SQL Package capability, and MySQL protocol and syntax support. Its enterprise-kernel lineage was later released as openHalo.
2023 — Halo 1.0.15
Procedural compatibility and Oracle sequence behavior continued to expand.
June 2024 — Second LTS
Halo 1.0.16 documented concurrent PostgreSQL, MySQL, and Oracle modes and additional distributed components.
Compatibility is part of the database path
E5 spans client protocol, parsing and semantic handling, optimization, and execution. Halo’s compatibility proposition is architectural—but every migration result remains workload-specific.
The documented product direction
Enterprise continuity and recovery
Replication, backup, PITR, grouped durability, and Shield lifecycle management.
Distributed access and placement
DLB, TWR, HSM, and HDS as distinct architecture patterns.
Database operations and visibility
Tuning surfaces, system metadata, HWR history, diagnostics, and DBA tooling.