OLTP on seven engines, OLAP on three — addressed natively.
The operational application is portable across seven relational engines — PostgreSQL, Informix, Oracle, DB2, SQL Server, MySQL and SAP HANA. Analytical workloads route to three OLAP engines — Vertica, ClickHouse and BigQuery. Native SQL generation across all ten — engine-native syntax, dialect, sequences and quirks emitted by the compiler, not a generic dialect the engine has to translate. A schema compiler that imports, sequences and modernises existing estates without translation. The data tier is engineered to a depth most platforms reserve for the application tier.
Ten engines, native SQL on each
Native SQL generation across all ten supported engines — engine-specific syntax, dialect, sequences and quirks emitted by the compiler. No generic dialect for the engine to translate at runtime.
OLTP application source, OLAP analytical back end
The same operational application runs on one of seven OLTP engines (PostgreSQL, Informix, Oracle, DB2, SQL Server, MySQL, SAP HANA). Analytical workloads route to one of three OLAP engines (Vertica, ClickHouse, BigQuery). Both sides share the same compiler.
XDBL — XML in, native SQL out
A database-independent XML grammar for DDL, DML, DCL and SPL. Write the schema and the procedures once in XDBL; the compiler emits native SQL for any of the supported engines — date arithmetic, string functions, sequence handling and dialect quirks resolved automatically. AI-targetable by construction, because the grammar is XSD-described.
Schema compiler with import
The customer's existing schema is imported as-is into the dictionary. Tables, indexes, constraints, stored procedures and triggers ported by recompilation, not by hand.
OLTP — seven supported engines, native SQL on each
The application runs on the engine the workload deserves. The application code does not change when the engine does — the compiler emits the engine-native SQL for each.
PostgreSQL
The default modern target. Open, deeply tested with the platform, full Tier-1 DBA depth from our team. Logical replication and CDC streaming to the analytical tier (Vertica, ClickHouse) supported natively. First-line recommendation for greenfield deployments and most modernisations.
Informix
The deepest engine in our practice. Data blades, Java extensions, CDC streaming, full Tier-1 DBA depth. The right answer when the customer's existing estate is on Informix or when the operational profile favours its strengths.
Oracle
Full schema, PL/SQL, package and job-scheduler support. Tier-2 development depth on our side; the customer's existing Oracle DBA practice owns operations. Common in Oracle Forms modernisation programmes.
DB2 · SQL Server · MySQL · SAP HANA
Supported as targets where the customer's existing estate or licensing landscape requires. Tier-2 development depth — full application engineering, with DBA-grade operations referred to vendor or partner. See airtool.io/services for the honest competence map.
OLAP — three analytical engines, same native-SQL compiler
Analytical workloads warrant a columnar back end. The same compiler that emits engine-native SQL for the seven OLTP engines emits engine-native SQL for these three.
Vertica
Native MPP query generation — projection-aware syntax, segmentation hints, hash-distribution joins, optimiser directives. The query plan that runs is the plan the analyst would have written by hand, generated automatically.
ClickHouse
Native columnar SQL — MergeTree-family syntax, partition pruning, sampling clauses, materialised views. The platform compiles to ClickHouse-native, not to a generic SQL the driver then has to reshape.
BigQuery
Native Standard SQL with BigQuery-specific extensions — partitioned and clustered tables, ARRAY / STRUCT semantics, ML-model invocation through SQL. Bytes scanned are minimised by query generation, not by manual tuning.
What the data tier actually does
Each capability is engineered, not assembled. The same engineers who write the platform write the data tier.
OLTP and OLAP under one roof
The application runs against the OLTP engine; analytical workloads route to the OLAP engine. One platform, one security perimeter, one audit trail. The split between transactional and analytical worlds is the runtime's concern, not the application's.
XDBL — XML grammar, native SQL output
A unified, database-independent XML grammar for DDL, DML, DCL and SPL. The same XDBL source recompiles cleanly against any supported engine — date arithmetic, string functions, sequence handling and isolation levels translate to each engine's native dialect. Schemas, stored procedures, triggers and queries are expressed once and ported by recompilation, not by hand.
XSD-described — and AI-targetable
The XDBL grammar is described by an XSD schema. An AI agent that knows the XSD can generate XDBL that compiles to perfect SQL on any supported engine — without knowing the engine. Date arithmetic, string functions and dialect-specific quirks are not the agent's concern; the compiler resolves them. The agent works at one level above SQL; the platform handles the engine. This is the foundation of the platform's AI-governance story — see the AI & MCP page for the security implications.
Schema compiler — two pipelines
MODEL processes table objects (tables, indexes, constraints, full-text indexes, seed data). CODE processes SPL objects in dependency order (CUDR → XUDF → XUDP → PROC → TRIG). LIKE-column resolution with circular-dependency detection. The compiler imports existing schemas and modernises them in place.
Multi-database, one application — and one AI surface
The application defines its model once. The platform recompiles it against the customer's chosen engine. Switching engines is a recompile-and-migrate operation, not a rewrite. Vendor lock-in at the data tier is engineered away by construction. When an AI agent emits XDBL instead of raw SQL, it inherits this database freedom automatically — the agent does not learn Postgres date syntax, Oracle string functions or ClickHouse MergeTree semantics ; the compiler resolves those at the same step the security model is injected. This is why governed AI scales across every supported engine without a per-engine prompt-engineering effort.
Transaction and integrity model
A consistent transaction model across the supported engines. Read-only and read-write transactions, savepoints, optimistic-concurrency hints and engine-specific isolation levels — surfaced uniformly so application code does not have to special-case per engine.
Data dictionary as the contract
The dictionary captures the data model — tables, columns, types, constraints, indexes — and the schema compiler emits the engine-specific DDL. Schema changes are dictionary changes, recompiled and applied; the contract between application and data tier is the dictionary, not the raw engine.
Why this matters for modernisation
Most legacy modernisations are forced into a database-engine choice at project start, before anyone knows whether the workload will be OLTP-heavy, analytical or mixed. The choice is irreversible; the project rebuilds the application around it; if the workload turns out to demand a different engine, the choice is paid for in performance for the rest of the system's life.
Airtool removes the irreversible choice. The application is portable across engines; the engine is changeable on the same platform; the modernisation programme keeps optionality where it matters most.