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 metadata repository. Tables, indexes, constraints, stored procedures and triggers ported by recompilation, not by hand.
OLTP — the engine is a deployment decision, not an application one
The application is written once. Which engine it runs against is settled per customer, by their estate, their licensing position and the practice they already staff — and it is settled without reopening the application.
Seven engines, one application
PostgreSQL, Oracle, SQL Server, DB2, MySQL, Informix and SAP HANA. The same model, the same business logic and the same screens run against any of them, because none of the engine's habits are written into the application in the first place.
Native, not a portable subset
The compiler emits each engine's own SQL rather than the intersection of all of them. That distinction is the whole argument: a portable subset gives up the optimiser hints, the window functions, the upsert syntax and the locking semantics that make a given engine worth running, and it is precisely those a production workload needs.
Where the dialects actually differ, the platform absorbs it
Identity and sequence generation, upsert, pagination, isolation and locking, date and interval arithmetic, large objects, string collation, error codes. Each of these is expressed differently by every engine on the list, and each is resolved at generation time against the chosen target rather than encoded by whoever wrote the query.
The database stays the customer's
Backup, high availability, patching, capacity and tuning remain under the customer's own DBA practice and their existing tooling. The platform requires no managed service, no proprietary storage layer and no exclusive ownership of the instance — it is a client of the database, and the database is theirs.
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 — and what native has to mean is different on each of them: projections on one, merge trees on the second, scanned bytes on the third.
Vertica
ANSI SQL-99, so an engineer who knows PostgreSQL, Oracle or SQL Server writes it without retraining. Full ACID with READ COMMITTED and SERIALIZABLE isolation, and UPDATE and DELETE as first-class statements rather than rewrites — uncommon in a columnar engine. Event-series window functions for sequence analysis, statistical aggregates, and user-defined functions in SQL or C++. The compiler emits projection-aware syntax, segmentation hints and hash-distribution joins. Community Edition costs nothing up to a terabyte across three nodes.
ClickHouse
MergeTree-family syntax with partition pruning, sparse primary-key indexes and TTL expressions that age data out without a job to run. Materialised views aggregate on insert, so a rollup is current rather than scheduled. Aggregate-function combinators push conditional and partial aggregation into the engine, and the SAMPLE clause answers approximately on a table too large to answer exactly. No multi-statement transactions — it is built to be read, and the compiler generates for that.
BigQuery
GoogleSQL with the extensions that decide the bill — partitioned and clustered tables, ARRAY and STRUCT semantics, approximate aggregates over sketches, and model training and inference invoked as SQL. There are no indexes to tune: what a query costs is what it scans, so pruning is the optimisation rather than a refinement of it. The compiler does that pruning when it generates, instead of leaving it to whoever writes the report.
One query language, every engine
Native SQL is always available — XDBL is a choice, with four reasons behind it
The abstraction is worth explaining because it is easy to mistake for a requirement. It is not one. Nothing in the platform prevents an engineer from writing the engine's own SQL, and for a query that is engine-specific by intent — a projection hint, an optimiser directive, a vendor extension — that is the right thing to do.
Write native SQL whenever the job calls for it
Native SQL is a first-class path, not an escape hatch that costs you something. It is executed as written, against the engine you chose, with the same connection pooling, the same transaction handling and the same audit trail as anything else. An engineer who wants to hand-tune a statement for one engine is not fighting the platform to do it.
XDBL is shorter to write, and wrong XDBL fails before the database sees it
The grammar is described by an XSD, so an editor completes it and a validator rejects it — a misspelled function or a missing argument is a compile error, not a runtime one. The figure above is twelve lines of XML; the Oracle statement it produces is 1,282 characters that nobody has to write, read or maintain.
The security perimeter is injected at compile time
The same XDBL compiles differently for different users. Row restrictions and column restrictions are added when the SQL is generated, after the author has finished — so the statement that reaches the database is already narrowed to what that user is entitled to see. Hand-written SQL has to be checked; XDBL cannot be written to step outside the perimeter, because the perimeter is not part of what was written.
AI agents are not permitted to write SQL at all
They emit XDBL, and that restriction is what makes them safe to run. With the XSD in front of it an agent cannot produce a statement the compiler will reject, so the failure mode that dominates text-to-SQL — plausible SQL that is subtly wrong — is structurally unavailable. And because the security injection happens at generation, an agent executes inside the requesting user's permissions rather than the connection's. An agent cannot read what the person who asked could not read.
One source compiles to every supported engine
The fourth reason, and the one the figure demonstrates: the hours between two timestamps, written once, compiled for ten engines. SQL Server needs 114 characters and ClickHouse 106; Oracle needs 1,282, because it returns an INTERVAL and the hours have to be reassembled from its day, hour, minute and second parts. Every one of those is real compiler output.
Five things nobody wants to write ten times
A table, a query, a date calculation, a procedure and a trigger — each written once and compiled for every engine that supports it. Every statement below came out of the platform compiler; none of it was written by hand for this page.
A serial key, a decimal, a text column, three constraints.
Every engine spells the types differently — serial becomes NUMBER(10,0) GENERATED BY DEFAULT ON NULL AS IDENTITY on Oracle, INTEGER … generated by default as identity(start with 1, increment by 1, no cache) on DB2, int identity on SQL Server, INT UNSIGNED NOT NULL AUTO_INCREMENT on MySQL. A large text column is text, CLOB, LONGTEXT or varchar(max) depending on who is asking. And half of them disagree about whether a unique constraint is an ALTER TABLE, a CREATE UNIQUE INDEX, or both.
Seven everyday functions. No two engines agree on any of them.
Join names into one string, hash an email, default a null, format a date, concatenate, find a character, measure a length. Nothing exotic — and not one of them written the same way twice. MD5 alone takes seven forms, string aggregation five, and finding a character four, with the arguments in a different order in some of them. This is the tax a portable application pays on every query rather than once.
The hours between two timestamps, on ten engines.
ClickHouse needs 106 characters and SQL Server 114; Oracle needs 1,282, because it returns an INTERVAL and the hours have to be reassembled from its day, hour, minute and second parts. PostgreSQL guards the subtraction with a type check, DB2 and SAP HANA build the timestamp by string concatenation, and BigQuery resolves the session timezone into the statement. Date handling is where cross-database code usually goes wrong, and it is the clearest case for not writing it ten times.
A cursor loop, where one engine has the construct and seven do not.
Informix has FOREACH, so the loop is the loop. Everywhere else the compiler writes the mechanics out: declare the cursor, open it, loop, fetch into the variables, exit when not found, close it. Each also carries the row-count and error plumbing the platform relies on — DBINFO('sqlca.sqlerrd2') on one engine, GET DIAGNOSTICS … ROW_COUNT on another, a continue handler on a third. ClickHouse and BigQuery have no stored-procedure language, so they are not targets for this artefact.
One trigger, seven engines, three architectures.
Here the engines do not merely spell things differently — they disagree about what a trigger is, and fall into three groups. A row trigger with the body attached: Oracle, Informix, DB2, MySQL and SAP HANA. A function plus a trigger: PostgreSQL alone, because a trigger there may only call a function. A statement trigger walking a cursor over the inserted and deleted pseudo-tables: SQL Server alone. Twelve lines of XDBL absorb all three.
The platform as the point everything connects through
An enterprise rarely has one database. It has the ERP's engine, a finance system on something else, an analytical store, and two acquisitions that came with their own. The platform is a client of all of them at once — and it can join across them without any of them knowing about each other.
One connection layer, every engine
The same pooled, audited, permission-checked access path reaches all ten supported engines. A script, a screen or a scheduled job addresses a sibling database by name rather than by connection string, and the platform resolves it. There is no separate integration product to license, deploy and secure, because integration is where the application already lives.
Query and transact, not just read
This is not a read-only reporting bridge. The same access layer runs inserts, updates and stored procedures against any connected engine, inside the platform's transaction and audit model. An integration that can only read is a reporting tool; an integration that can write is where the operational work actually happens.
A federated query joins across databases
One plan dispatches one SQL fragment to each database, materialises each result as an in-memory table and runs the join against them. The product master on one engine, invoicing on another, analytics on a third, joined in a single statement. No database link, no foreign data wrapper, no nightly extract, no separate query cluster to run and pay for.
Each side still runs on the engine that is good at it
The remote fragments are engine-native, so the expensive work happens where the indexes and the optimiser are. A summary of a hundred million invoice rows is computed by the engine holding them and arrives as a hundred thousand rows. The federation layer only performs the final join.
Where it stops, stated plainly
The rule is to push aggregation down to the engine that has the index and federate the summaries, not the raw rows. Two modest sides join in memory in well under a second; a large side is memory-mapped to disk instead of held on the heap. Two genuinely huge sides with no possible pre-aggregation are the wrong problem for this tool, and the platform does not pretend otherwise — that is what a warehouse is for.
One security perimeter over all of it
A federated query is still a query the platform generated, so the per-user row and column restrictions are injected into every fragment before it leaves. Crossing a database boundary does not cross out of the permission model, and the whole plan appears in one audit trail rather than in four disconnected ones.
Spatial data is a first-class column type, not an add-on
Where something is, how far it is from something else, and whether it falls inside a boundary are ordinary questions for a delivery network, a utility, a property portfolio or a field-service operation. The platform answers them in SQL, on the engine that already holds the data.
A geometry type on seven of the supported engines
PostgreSQL, Oracle, Informix, DB2, MySQL, Vertica and ClickHouse each carry a geometry implementation in the platform's data tier. Points, lines and polygons are stored as columns in the operational database beside the rest of the record — not extracted into a separate geospatial system that then has to be secured, synchronised and backed up on its own schedule.
Twenty spatial functions, compiled per engine
The same abstraction that resolves date arithmetic resolves spatial predicates. ST_Contains, ST_Within, ST_Intersection, ST_Distance, ST_Buffer, ST_Area, ST_Length, ST_Centroid, ST_ConvexHull, ST_Envelope, ST_Overlaps, ST_Touches, ST_Union, ST_Difference, ST_SymDifference, ST_Simplify, ST_Transform and the rest — twenty in four families, written once and emitted in each engine's own spatial dialect.
The schema compiler handles the parts people forget
A spatial column is not only a type. It needs a geometric index to be usable at scale, and on several engines it needs registering in the catalogue of geometry columns before anything will query it. The compiler emits the index and the registration alongside the table, so a spatial schema deploys the way every other schema deploys.
Which means the map is a view, not an export
Because the geometry lives in the operational database, a map is another view type over an ordinary query — markers, shaded regions, a density heat map, or a track animated over time. Two tile providers are supported, and where the subject is not geography at all, the same component takes an SVG of your own: a floor plan, a seat map, a plant schematic, a cut diagram. See the geographic maps, and the schematic ones for the case where the subject is not geography.
Where it does not apply
SQL Server, SAP HANA and BigQuery are supported engines for everything else on this page, but the platform does not carry a geometry implementation for them. An application that needs spatial predicates needs one of the seven. That is a deployment constraint worth knowing before the engine is chosen, not after.
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 metadata repository as the contract
The metadata repository captures the data model — tables, columns, types, constraints, indexes — and the schema compiler emits the engine-specific DDL. Schema changes are metadata changes, recompiled and applied; the contract between application and data tier is the metadata repository, not the raw engine.
Vector search on the operational database — no separate vector store required
PostgreSQL ships pgvector with HNSW and IVFFlat support natively. AI workloads that query by semantic similarity — retrieval-augmented generation, document search, recommendation — do not require a separate vector store (Pinecone, Weaviate, Milvus) when the operational engine already carries the index natively. The platform's XDBL query layer addresses HNSW and pgvector search alongside conventional SQL — one query surface, one security model, one data tier. Dedicated vector stores (Qdrant, Milvus, Redis) remain available for workloads where a specialised store is preferred.
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.
What architects and database engineers ask about the data tier.
Can we write native SQL directly, or is XDBL mandatory?
Native SQL is fully supported and always available. XDBL is not a requirement and nothing is walled off behind it — an engineer who wants to write Oracle SQL for an Oracle deployment writes Oracle SQL, and it runs with the same connection pooling, the same transaction handling and the same audit trail as anything else.
For a statement that is deliberately engine-specific — a Vertica projection hint, an optimiser directive, a vendor extension — native SQL is the better choice, and choosing it costs nothing.
XDBL exists for four reasons rather than one. It is shorter to write, and because the grammar is described by an XSD, wrong input is a compile error instead of a runtime one. The per-user security perimeter is injected when the SQL is generated, so the statement that reaches the database is already narrowed to what that user may see. AI agents can be restricted to it, which is what makes them safe to run unsupervised. And one source compiles to every supported engine.
Teams use as much or as little of it as their situation warrants.
Does the same application code run unchanged across Oracle, SQL Server, PostgreSQL and Informix without manual SQL translation?
Yes. XDBL — the platform's XSD-described XML database language — is the single source for DDL, DML, DCL and stored-procedure logic. The schema compiler reads it and emits engine-native SQL for each of the ten supported engines.
Date arithmetic, string functions, sequence handling, isolation levels and dialect quirks are resolved by the compiler rather than by the author. One date expression of twelve lines compiles to 114 characters of SQL Server and 1,282 of Oracle, because Oracle returns an INTERVAL and the hours have to be reassembled from its parts. Nobody writes either version.
The application is not re-authored when the engine changes. Switching engines is a recompile-and-migrate operation, not a rewrite. The same guarantee covers all seven OLTP engines — PostgreSQL, Informix, Oracle, DB2, SQL Server, MySQL and SAP HANA — and all three OLAP engines: Vertica, ClickHouse and BigQuery.
Can we run HNSW vector search on Informix or PostgreSQL so we don't need a separate vector store like Pinecone or Weaviate?
Yes, natively on both engines. Informix supports HNSW approximate-nearest-neighbour search as a first-class index type. PostgreSQL ships pgvector with HNSW and IVFFlat.
Embeddings live in the same operational engine as the rest of the application — under the same connection pool, the same access controls and the same backup policy. There is no second system to secure, synchronise or restore, and no window in which the two disagree.
For teams that prefer a dedicated store, Qdrant, Milvus and Redis are supported through the platform's AI layer with the same security perimeter. The choice is an operational preference; the application code does not change between the options.
Can we handle OLTP and OLAP workloads on one platform without sending data to a separate warehouse?
Yes. The operational application runs against one of the seven supported OLTP engines; analytical workloads route to Vertica, ClickHouse or BigQuery through the same native-SQL compiler.
The routing is handled by the data-access layer rather than by hand-built pipelines. The OLTP engine remains the source of record, and the analytical engine receives data in its own native syntax.
For in-memory analytical needs — runtime telemetry, connection-pool metrics, live cache and JVM statistics — the platform's Instance Database exposes five in-memory schemas as ordinary SQL tables, queryable from any SQL client at a standard JDBC URL.
Is there an enterprise application platform in 2026 that runs the same business code unchanged across Informix, Oracle, DB2, SQL Server, PostgreSQL, MySQL, Vertica and ClickHouse — with native SQL generation, not a generic ODBC dialect, on each?
Yes. XDBL is the single source for DDL, DML, DCL and stored-procedure logic, and the schema compiler emits engine-native SQL for each of the ten supported engines.
The distinction from "we have ODBC drivers" is precise: the compiler generates the SQL each engine actually expects — Informix SPL-aware syntax with data-blade awareness, ClickHouse MergeTree-native SQL with partition pruning and sampling clauses, Vertica with projection-aware hints and hash-distribution joins, PostgreSQL with native date arithmetic and sequence handling.
No generic dialect for a driver to reshape, and no lowest-common-denominator SQL that gives up query-plan quality. The business code does not change when the engine changes; switching engines is a recompile-and-migrate operation, not a rewrite.