One platform for the full life of a large enterprise application.
One supervised runtime that owns the full lifecycle — develop, manage, deploy, scale. OLTP transactions and OLAP analytics on the same engine, no external BI stack to license or operate. Applications authored as metadata, not code — no per-screen Vue, no theme CSS, no role-branching boilerplate. Developers stay close to the business, not buried in the stack.
Applications authored as metadata
Forms, grids, dashboards, reports, server-side logic, batch jobs — every artefact a row in the Metadata Repository, materialised by the runtime. No per-screen Vue, no theme CSS, no role-branching boilerplate. Hot-reload propagates cluster-wide in milliseconds.
OLTP and OLAP on the same platform
Seven OLTP engines for the operational application ; three OLAP engines (Vertica, ClickHouse, BigQuery) for analytical workloads. Interactive dashboards on the customer's own infrastructure, behind the customer's own security perimeter. No external BI to license.
Supervised execution, governance everywhere
The platform owns HTTP, threads, pools, sessions, security, observability and audit. Eight authentication mechanisms under one dispatcher ; row and column security on every query ; multi-tenant isolation at the JDBC layer.
One platform, full application lifecycle
Database Workbench for development, Studio cockpit for operations, cluster-coordinated zero-downtime deployment. Observability as SQL — no external APM, no separate analytics warehouse, no third-party monitoring tier.
What the platform actually gives you
Forms, dashboards, reports, server code, batch jobs — all from one editor.
The Application Editor — a visual authoring surface inside the browser — composes everything the application is made of, not just its UI. Forms, grids, dashboards and reports compose from a 100+ component palette of inputs, data views, charts and widgets. Server-side business logic, scheduled jobs, batch processing and REST API endpoints are authored in the same tool, in the same browser, against the same repository metadata. Drop a component onto one of five layout regions; wire it to a database column; save. Foreign-key autocomplete is recognised from the repository metadata; the editor suggests the widget; one click wires it. Save invalidates the Metadata Repository cache cluster-wide via Redis pub/sub and the new version — including any newly-authored REST endpoints — materialises live in milliseconds, no JAR rebuild, no redeploy. Developers stop writing Vue components, theme CSS and role-branching logic; they own the data model and the business rules. The platform owns the rest.
See the developer experienceInteractive dashboards. On your infrastructure. At a fraction of the per-seat cost.
Analytical workloads run against Vertica, ClickHouse or BigQuery with native SQL generation — no generic dialect for the engine to translate, no third-party connector to maintain. Cubes, dimensions and measures are defined as repository metadata; reports, KPI surfaces and interactive dashboards are composed inside the platform from the same authoring model that produces the operational application. Drill-down, drill-across, slice-and-dice, cross-filtering — the interactive analytics surface a business analyst expects: click a slice of a pie, every related chart, table and KPI on the dashboard updates against the same governed query. The capability set matches and in places exceeds what PowerBI, Tableau and Looker deliver. The differentiator is the deployment model : analytics runs on the customer's own infrastructure, behind the customer's own security perimeter, governed by the same row-level and column-level security that protects every OLTP transaction — at a fraction of the per-seat licence cost a SaaS BI stack would charge for the same audience.
Read the data briefLike AWS Console — but for the application platform itself.
Studio is the operator's cockpit for the running platform — an AWS-console parallel for an enterprise application estate. User and role administration with eight authentication mechanisms unified under one dispatcher, MFA policies per department, certificate keystores per user, instant offboarding that kills database, API and session access in one action. Service and resource control: cluster topology, database fleet, connection-pool tiers, replica routing, multi-tenant isolation enforced at the JDBC layer. AI governance: provider configuration, per-company and per-user budget caps, model-selection policy, live cost dashboards by user, department and model. Scheduled automation, integration credentials, certificate rotation. Audit trails — every login, every query, every transaction, every AI invocation — captured and queryable as SQL.
See the operations modelEight mechanisms, one perimeter, observable as SQL.
Eight authentication mechanisms unified under a single dynamic dispatcher: HTTP Basic, Digest, Form + 2FA (TOTP, Email OTP, SMS), JWT Bearer, OAuth 2.0, OpenID Connect, SAML 2.0, mTLS. Mix LDAP, SSO and certificates in one installation, per request. Audit is mandatory — every login, every REST call, every DML write, every AI invocation, every active session — captured and queryable as standard SQL. The Instance Database at jdbc:axional:memory:instance exposes JVM, JDBC, cache, statistics and machine schemas as SQL tables; SELECT * FROM jvm.memory replaces the external APM tier.
See the security modelAI bound by the same security model as the user.
The substrate matters as much as the model. Because every form, screen, role, query and batch is a database record — not a file — AI agents author the same graph developers do, not a file tree they have to parse. Multi-provider chat across OpenAI, Anthropic, Ollama, Google Vertex, IBM Watson and Cohere — swap providers via configuration, not code. Built-in RAG over the customer's choice of vector store (Qdrant, Milvus, PostgreSQL pgvector or Redis). Natural-language agents emit XDBL — the platform's XSD-described query grammar, not raw SQL ; agents don't learn seven SQL dialects, they write one XDBL and the compiler emits the rest with row- and column-level security injected at the same step. The agent works one abstraction level above SQL ; the platform handles engine, dialect, isolation and security. A native MCP server so external assistants drive the platform without bypassing it.
Read the AI briefThe platform, in numbers
The numbers that anchor the platform — verifiable, not rounded.
Start where it makes sense for your organisation
Greenfield Deployment
Stand up Airtool with the included application suite — ERP, CRM, HR and Project Management — as the operational core. Modernisation programme runs in parallel through Modernisation methodology.
Plan a greenfield deployment →Legacy Modernisation
Replace a legacy estate (Informix 4GL, Oracle Forms, Delphi, PowerBuilder, custom ERPs) on Airtool, with the schema-first, database-business-logic-preserving methodology. Incremental cut-over, business runs through migration.
Read the modernisation methodology →Module Augmentation
Keep the existing ERP core. Add Airtool-hosted analytics on Vertica or ClickHouse, AI-native applications, or specialised modules — connected via the platform's microservice and integration surfaces.
Explore module augmentation →The platform's most credible demonstration is the platform's own application suite.
Airtool Apps — ERP, CRM, HR and Project Management — runs on this runtime. The same metadata model, the same OLTP and OLAP engines, the same supervised execution, the same AI and MCP perimeter, the same observability surface described above. The suite is not an example; it is the platform proving itself with production-grade enterprise software shipped to real customers.
An architect evaluating Airtool against an in-house build or a JVM-class framework can see, in Apps, what the runtime produces in practice — four applications, zero front-end code, every platform-core capability inherited by every screen and every report. Any application built on Airtool — bespoke, partner-extended or modernised — inherits the same.
Developers move near the business — not the other way round.
The conventional enterprise stack forces the business to move toward the developer : describe the requirement, wait for the sprint, validate the build, hope the deployment window fits. Each translation step is a place where intent gets lost. Each hand-off between front-end, back-end, data team and operations is a place where ownership thins.
Airtool collapses the translation. Forms, screens, reports and cubes are repository metadata authored in a browser tool that the data engineer, the consultant and the business analyst can all read. Business logic is server-side JavaScript with full autocomplete and AI-assisted authoring, hot-reloaded across the cluster in milliseconds. Reports run in the same tool the application runs in. The full-stack developer — the rare, expensive role the conventional stack demands — is not required, because the platform absorbs the stack.
The result is an organisation where developers stay close to the data model and the business rule, and where the business can see, verify and iterate on the application without leaving the engagement.
The architecture questions buyers ask first.
What does it actually mean to say the application is metadata, not code?
Every form, screen, role, query, dashboard, report, server-side handler and batch job is stored as rows in a Metadata Repository — not as files in a source tree. The runtime materialises the application surface from those rows on demand, with cluster-wide hot-reload in milliseconds via Redis pub/sub. The implication : there is no per-screen Vue to maintain, no theme CSS to fork, no role-branching boilerplate to keep in sync. New screens are metadata inserts ; new rules are metadata updates ; the runtime is the same runtime that has been operating the existing application.
How is OLTP and OLAP on the same platform different from a typical stack?
A typical stack runs the operational application on one engine and licenses an external BI tool — PowerBI, Tableau, Looker — to deliver analytics, with per-seat fees, a separate security perimeter and a connector to maintain. The platform delivers both layers natively : OLTP on one of seven supported engines, OLAP on Vertica, ClickHouse or BigQuery, with native SQL generation, dashboards composed in the same authoring tool that produces operational screens, and the same row-level and column-level security applied to both.
Which OLTP engines are first-class — and what does first-class mean?
Seven engines : PostgreSQL, Informix, Oracle, DB2, SQL Server, MySQL and SAP HANA. First-class means the SQL compiler emits engine-native SQL — not a generic dialect translated by the engine — and the schema-code processor and the platform's standard library operate against the engine in production. The customer chooses the engine ; the platform recompiles the metadata against that engine at runtime.
What is the supervised runtime, and what does it stop applications from doing?
The platform owns HTTP, threads, pools, sessions, security, observability and audit. Applications run inside a controlled execution policy — they cannot claim infrastructure, cannot bypass tenant isolation, cannot reach outside the perimeter the runtime defines. Misbehaviour degrades the application, never the host. Eight authentication mechanisms unify under one dispatcher ; row-level and column-level security inject into every query ; multi-tenant isolation enforces at the JDBC layer.
Is observability a separate stack, or part of the platform?
Part of the platform. The Instance Database at jdbc:axional:memory:instance exposes JVM, JDBC, cache, statistics and machine schemas as SQL tables. SELECT * FROM jvm.memory is the canonical example — observability is queryable as SQL through the same surfaces the application uses. There is no external APM tier to license, no separate analytics warehouse to operate, no third-party monitoring stack to keep in sync.
Who authors the application — developers, business analysts, or both?
Both, through the same tool. The Application Editor in the browser composes forms, grids, dashboards, reports, server-side handlers and batch jobs from a 100+ component palette. Business-side authors compose the surface ; engineers author the rules and the platform-side extensions. The customary divide between "developers who write the UI" and "analysts who specify the requirements" closes because the artefact is one Metadata Repository, not two codebases.