MODERNIZE
Compatibility and migration
Assess protocols, types, SQL semantics, procedural logic, metadata, and integration dependencies against the workload you intend to move.
HALO DATABASE PLATFORM
A unified database platform for compatibility-led modernization.
Halo is a general-purpose database built on the openHalo kernel. It combines Oracle, MySQL, and native PostgreSQL operating modes with transactional storage, continuity, recovery, distributed-data options, and DBA tooling.
The documented platform at a glance
- 3operating modes
- Oracle, MySQL, and native PostgreSQL paths can coexist in one instance.
- 4E5 layers
- Protocol, parsing and semantics, optimization, and execution.
- 6core index methods
- B-tree, Hash, GiST, SP-GiST, GIN, and BRIN.
- 45documented extensions
- Grouped across data, integration, security, and diagnostics.
PLATFORM MODEL
One kernel, three application paths
Each operating mode has its own connection and behavior layer. The underlying Halo kernel provides the database foundations beneath those paths.
APPLICATIONS
Oracle · MySQL · PostgreSQL
Drivers, tools, and application traffic.
INDEPENDENT ENDPOINTS
Compatibility entry
Protocol and mode-specific connection behavior.
E5 FOUR-LAYER MODEL
Interpret and execute
Protocol · semantics · optimizer · execution; PostgreSQL is the native, no-extension mode.
HALO KERNEL
Database foundations
Transactions · WAL · storage · indexes · partitions · visibility.
Compatibility is implemented across the request path, not presented as syntax conversion alone. Coverage and boundaries remain mode-specific.
What the platform covers
BUILD
Core database foundations
ACID transactions, MVCC isolation, WAL durability, savepoints, rich indexing, multilevel partitioning, and a broad object model.
PROTECT
Availability and recovery
Physical and logical backup, point-in-time recovery, streaming and logical replication, readable replicas, grouped replication, and Halo Shield.
DISTRIBUTE
Data placement and access
DLB, TWR, HSM, and HDS address read scaling, write forwarding, shared storage, and sharded data as distinct topologies.
OPERATE
Visibility and control
HWR reports, system catalogs and views, diagnostic modules, resource controls, and DBeaver integration support DBA workflows.
EXTEND
Data and extensions
Optional modules cover integrity, indexing, data types, search, federation, security, events, sampling, and model/runtime registries.
Choose the topology that matches the problem
| Topology | What it adds | Decision to validate |
|---|---|---|
| Single Halo cluster | Multiple databases, transactional storage, WAL, and native visibility | Workload behavior and resource design |
| Replicated service | Primary and readable standbys with synchronous or asynchronous streaming | Commit latency, lag, and data exposure |
| Managed high availability | Shield coordination, health checks, fencing, role management, and VIP movement | Quorum, failover, reconnect, and maintenance |
| Read-scaled access | DLB read distribution and optional TWR write forwarding | Read freshness and routing behavior |
| Distributed placement | HDS sharding or HSM shared-storage architecture | Data model, failure boundary, and operations |
A roadmap shaped by migration practice
2012 — Origin
Halo development began in response to an Oracle application migration challenge; SYSDATE was the first recorded compatibility keyword.
2021 — Halo 1.0.13
The first V1 release 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.
2023 — Halo 1.0.15
Procedural and Oracle sequence behavior continued to expand.
June 2024 — Second LTS
Halo 1.0.16 documented multiple operating modes in one instance and additional distributed components. The enterprise kernel lineage was later released as openHalo.
Turn the platform map into a workload decision.
Define the application dependencies, target architecture, and acceptance evidence before selecting a migration or deployment path.