Operational dashboard
Real-time operational dashboard
Live aggregations against the OLTP application source. Row-level security injected by the compiler — every user sees only what their grants allow.
Platform · Analytics & Reporting
Operational reporting and analytics, engineered into the runtime.
Enterprise-grade analytics without per-seat BI licensing or cloud data ingest. ClickHouse — open source, supported by the platform team — and Vertica Community Edition run on the customer's own infrastructure. No ETL pipeline. No data leaving the security perimeter. Analytical queries run against live operational data — drill from a ClickHouse aggregate to the originating OLTP record in clicks, without leaving the platform. Page-perfect reports, drill-down through hierarchies, and native SQL against the analytical engine the workload deserves.
Page-perfect, pixel-perfect output
Regulated invoices, statutory filings, audit packs and customer-facing documents rendered with the layout discipline production requires — not the rough sketch a generic BI tool produces.
Business operational reports
The reports the business actually runs the business with — sales registers, ageing schedules, stock movements, production yield, payroll registers — on live operational data, in real time.
Drill-down and drill-across
Drill down through hierarchies (group → company → entity → record), drill across between data sources (operational → analytical → external). Reconstruct any figure to its source in clicks, not project plans.
Open-source analytical engines, no per-seat cost
ClickHouse is open source; Vertica Community Edition is free to one terabyte. Both run on the customer's infrastructure, supported by the platform team. No per-seat BI licence. The platform generates engine-native SQL for each — not generic SQL the engine has to translate.
Page-perfect and pixel-perfect reporting
Where the layout is the deliverable — regulated, customer-facing or audit-grade output that has to render exactly as designed.
Pixel-perfect rendering
Page layout, font, table formatting, headers, footers, watermarks and pagination controlled at design time. The rendered output is the print artefact — not a screenshot of a dashboard.
Statutory and regulated output
Invoices, payroll registers, fiscal returns, statutory disclosures and customer-facing documents formatted to the standard the regulator or counterparty expects. The fiscal calendar drives the schedule; the engine drives the format.
Multi-format output
Same report definition renders to PDF (PDF/A for archival), XLSX, CSV, HTML, plain text — without redesign per format. Output channel becomes a runtime parameter.
Scheduled and event-driven generation
Reports generated on the fiscal calendar, on operational events, or on demand. Output routed by email, deposited on storage, surfaced in the application — handled by the same runtime.
Business operational reports
The reports the operation depends on every day. Not dashboards — reports, with the rigour and audit trail enterprise operations require.
Real-time operational reports
Sales registers, supplier ageing, stock positions, production yield, work-in-progress, cash flow — all running against live operational data, not against last-night's data warehouse extract.
Audit-grade traceability
Every figure on every report is traceable to its source record. Drill-through lands the analyst at the originating transaction, with timestamps, user identity and approval chain intact.
Multi-entity, multi-currency, multi-fiscal-regime
Group consolidations, entity-level views, currency translation, fiscal-regime parallel reporting (statutory and management views side-by-side). The reporting plane reflects the operational reality.
Role-aware visibility
The same report definition shows different data to different roles. Security expressions injected automatically; the report builder does not need to know the security model to honour it.
Drill-down and drill-across
Reconstructing a figure to its source is a property of the platform, not a feature added to one report at a time.
Drill-down through hierarchies
From group consolidation to legal entity to cost centre to GL account to the originating transaction — in clicks, not in queries. The hierarchy is configured once and applies across every report that touches it.
Drill-across between data sources
From an operational report to an analytical view on Vertica or ClickHouse, from a customer summary to an external CRM record, from an inventory position to the upstream supplier feed. Lateral movement across data sources is a property of the platform.
Cube drill-paths
OLAP cubes with configurable dimensions and hierarchies. Drill into a measure across any dimension; pivot the result; export the view; share it with a colleague. The cube is built once and serves every drill-path.
Audit trail follows the drill
Every drill-through is logged. Who looked at what, when, from where. The exploratory analytics surface is itself audit-grade.
Native SQL generation for analytical engines
When the workload warrants a columnar or MPP analytical engine, the platform generates native SQL against that engine — not generic SQL the engine then has to translate.
Vertica
ANSI SQL-99 compliant — developers who know PostgreSQL, SQL Server or Oracle work with Vertica without dialect retraining. Full ACID transactions; UPDATE and DELETE are first-class operations. Community Edition at no cost to one terabyte; the platform team supports both the CE and enterprise tiers.
ClickHouse
Open source, Apache 2.0 — zero engine licence cost at any scale. Native columnar SQL: MergeTree-family syntax, partition pruning, sampling clauses, materialised views — compiled by the platform. Independently benchmarked at benchmark.clickhouse.com.
BigQuery
Native Standard SQL with BigQuery-specific extensions — partitioned and clustered tables, ARRAY / STRUCT semantics, ML model invocation through SQL. Bytes scanned minimised by query generation. The right choice when the data strategy is already Google Cloud-anchored.
Mix-and-match by workload
OLTP stays on the application's operational engine. Analytical workloads route to the engine the workload deserves. The same platform serves both; the analyst sees one query surface. The choice of analytical engine is an operational decision — not an architectural constraint locked in at project start.
Vertica — MPP analytics on a familiar SQL surface
A column-oriented MPP engine that speaks standard ANSI SQL. The right choice when the team needs serious analytical power without changing the SQL they already write — and when the workload includes row-level modifications alongside analytical queries.
SQL your team already writes
ANSI SQL-99 compliant. Developers fluent in PostgreSQL, SQL Server or Oracle move to Vertica without learning a new query language. Window functions, aggregates, sub-queries, CTEs and stored procedures behave exactly as those developers already expect. No dialect retraining; no legacy SQL to port.
Full ACID and first-class modifications
READ COMMITTED and SERIALIZABLE isolation. UPDATE and DELETE are immediate, first-class operations — not background mutations. Vertica is not an append-only engine. It handles the full write surface of a traditional relational database while delivering columnar analytical performance: the right profile when business data requires corrections, amendments and master-data management alongside heavy analytics.
Analytical functions and user-defined extensions
A large built-in function library covering the full analytical surface: window functions (RANK, DENSE_RANK, LAG, LEAD, FIRST_VALUE, LAST_VALUE, PERCENTILE_CONT, PERCENTILE_DISC), statistical aggregates (STDDEV, VARIANCE, CORR, COVAR_POP), and event-based windows for sequence analysis. User-defined functions authored in SQL or C++ and deployable without restarting the engine.
Community Edition to one terabyte
The full Vertica engine at no licence cost for deployments up to one terabyte on three nodes. Enterprise licensing for larger deployments. The platform team provides production support on both tiers — the Community Edition entry path does not require a separate Vertica support contract.
ClickHouse — open-source columnar engine built for speed
An analytical database engineered for insert throughput and query speed at large scale. Open source under the Apache 2.0 licence. The right engine when the workload is append-heavy and analytical query performance on large datasets is the priority.
Open source, zero engine licence cost
Apache 2.0 licence — deploy on the customer's own servers at any data volume, with no per-node or per-terabyte engine charge. The platform team provides production support. The licence cost of the engine is zero regardless of scale.
Columnar storage and compression
Data stored column-by-column rather than row-by-row. Analytical queries that aggregate a subset of columns read only those columns; the rest of the table is untouched. Column-level compression with engine-selectable codecs achieves typical ratios of 2–3× on general data and considerably higher on low-cardinality columns. Query throughput scales with available CPU cores.
MergeTree: built for ingestion at scale
Inserts create immutable data parts that are merged in the background. The write path is lock-free; incoming data never blocks waiting for merge completion. Insert throughput scales linearly with CPU cores — millions of rows per second on standard hardware. The right architecture for event streams, log pipelines, time-series data, metrics and user behaviour at high volume.
Materialized views with incremental refresh
Materialized views refresh incrementally on each insert, not on a polling schedule. Aggregates stay current as source data arrives; high-frequency analytical dashboards query pre-computed results without rescanning the full dataset. For workloads requiring a full recompute on a schedule, refreshable materialized views run on a configurable interval with optional append-only mode.
In the product
Analytics and reporting, as the user sees them
Dashboards, drill-down, OLAP and pixel-perfect output — from one platform, addressing three workloads. Placeholder screenshots; real captures land in this same carousel.
1 / 4
Why this matters
Enterprise analytics has fragmented over the past decade — one tool for pixel-perfect statutory output, one for executive dashboards, one for ad-hoc analysis, one for the data warehouse, one for the AI agents that try to read all of the above. Each tool has its own access model, its own pricing, its own lag. The operator paying for them rarely sees a single coherent analytical picture; the auditor sees four different versions of the same number.
Airtool collapses the stack. Page-perfect output, business operational reports, drill-down across the operational and analytical layers, and native query generation against the analytical engines that warrant a columnar back end all run on the same platform, against the same data, under the same security perimeter and the same audit trail. There is one number — visible in the operational report, in the executive dashboard, and in the analytical view — because there is one source of truth.
What the economics of on-premises analytics actually look like.
The typical enterprise analytics stack bundles a per-seat BI platform licence with a cloud data warehouse. The per-seat cost compounds with headcount; the cloud ingest cost compounds with data volume; the ETL engineering to connect the two is a recurring build-and-maintain obligation. Then the data leaves the customer's perimeter — it lives in Azure, in Redshift, in BigQuery — and the compliance and governance exposure lives there with it.
ClickHouse is open source under the Apache 2.0 licence. Vertica Community Edition is free to one terabyte on three nodes. Both run on infrastructure the customer already operates. The platform team provides production support on either engine. The per-seat BI licence cost does not exist. The cloud ingest pipeline does not exist. The data stays on the customer's infrastructure, under the customer's security model, queryable in real time against the operational data source — the record updated by the business an hour ago is visible in the next analytical query.
The drill-to-source capability — from a ClickHouse aggregate down to the originating OLTP transaction — is only possible because the OLTP and the OLAP engines run on the same platform, with no data copy between them. No SaaS BI platform can replicate this: they all consume a copy of the data, so the drill terminates at the copy. Airtool terminates at the source.
On-premises analytics versus the cloud BI stack
| SaaS BI platform (PowerBI · Tableau · Looker) | Cloud data warehouse (Azure Synapse · Amazon Redshift) | Airtool Analytics on ClickHouse or Vertica | |
|---|---|---|---|
| Analytical engine cost | Per-seat monthly licence; scales with headcount | Per-query or per-TB processed, plus a separate BI tool licence | ✓ ClickHouse open source (Apache 2.0); Vertica CE free to 1 TB. Platform support included. |
| Data location | Cloud vendor infrastructure | Cloud vendor infrastructure | ✓ Customer's own infrastructure |
| ETL to analytical layer | Required — data must be ingested, refreshed and reconciled | Required — full ingest pipeline to build and maintain | ✓ None — analytical queries route from the application's data tier automatically |
| Data freshness | Last-refresh lag — minutes to hours behind operational state | Last-load lag — depends on ingest cadence | ✓ Live — queries run against current operational data |
| Security perimeter | Data leaves the customer's infrastructure to the BI vendor's cloud | Data leaves the customer's infrastructure | ✓ Data stays on customer infrastructure, under the customer's security model |
| Drill to originating transaction | Via connector, with delay and data-copy exposure | Not available — the warehouse is a copy, not the source | ✓ Direct — same platform, same metadata model, same security perimeter |
| On-premises deployment | Limited or unsupported | Cloud-only by design | ✓ Native — the default deployment model |
Analytics questions
What enterprise buyers ask about the analytical tier.
We already have SQL engineers on staff. Do they need to learn a new tool to work with Vertica?
No. Vertica is ANSI SQL-99 compliant. Engineers who write against PostgreSQL, SQL Server or Oracle work with Vertica without dialect retraining — window functions, aggregates, sub-queries, CTEs, stored procedures and user-defined functions all behave as those engineers already expect. The difference from a general-purpose relational engine is architectural: Vertica stores data in a columnar format optimised for large analytical scans, distributes execution across nodes (MPP), and is designed for analytical throughput rather than high-concurrency row-level writes. The SQL surface the analyst sees is standard; the engine underneath is engineered for the analytical workload. UPDATE and DELETE are fully supported and are first-class operations — Vertica is not an append-only engine. For workloads requiring rich statistical computation, Vertica ships a large built-in analytical function library: window functions (RANK, DENSE_RANK, LAG, LEAD, PERCENTILE_CONT, PERCENTILE_DISC, FIRST_VALUE, LAST_VALUE), statistical aggregates (STDDEV, VARIANCE, CORR, COVAR_POP), and event-based windows for sequence analysis. User-defined functions can be authored in SQL or C++ and deployed without restarting the engine.
What does it mean to run analytics on the same platform as the operational application — rather than shipping data to Azure Synapse or Snowflake?
It means the analytical query runs against data that was written by the operational application minutes or seconds ago — not against last night's export. Cloud data warehouses (Azure Synapse, Redshift, Snowflake, BigQuery) all work from a copy of the operational data. Getting the data there requires an ETL pipeline to build, schedule and monitor; the analytical result is as fresh as the last successful load; and the data leaves the customer's infrastructure to live in the vendor's cloud. On Airtool, Vertica or ClickHouse run on the customer's own servers. The platform routes analytical queries to the OLAP engine automatically — there is no ETL pipeline to build. Drill-down from a Vertica aggregate to the originating OLTP transaction is direct, because both engines run on the same platform under the same security model. The analyst sees today's data, not yesterday's export. The data never leaves the customer's perimeter.
How does Vertica Community Edition compare to a paid cloud analytical warehouse for an initial deployment?
Vertica Community Edition is available at no cost for deployments up to one terabyte of data on up to three nodes. It carries the full Vertica SQL engine, the complete analytical function library, and MPP execution. For an organisation that is evaluating whether a columnar analytical engine fits its workload — or that has an analytical dataset well under one terabyte — the Community Edition is a production-capable starting point with no engine licence cost. The platform team provides support on the CE tier alongside the enterprise tier. The comparison against a cloud analytical warehouse is direct on cost: a cloud warehouse charges per query or per terabyte processed, compounds with every user who accesses the analytical surface, and requires the data to leave the customer's perimeter to reach the cloud. Vertica CE is an on-premises deployment; the cost of the engine is zero; the data stays where it is.
Our data includes high-volume event streams and logs alongside business data that needs regular corrections. How should we structure the analytical tier?
Different data patterns suit different engines, and the platform supports both on the same deployment. Event streams, logs, user behaviour and time-series workloads suit ClickHouse: the MergeTree engine accepts inserts at millions of rows per second without blocking, compression is excellent on repetitive columnar data, and materialized views keep aggregates current in real time as data arrives. Business data that requires row-level corrections — financial adjustments, order amendments, master-data updates — suits Vertica, where UPDATE and DELETE are immediate first-class operations under full ACID guarantees. The two engines can operate on the same Airtool platform; analytical queries route to the engine whose characteristics match the workload. The application code and the security model do not change between them.
ClickHouse handles UPDATE and DELETE differently from a standard relational database. Does that limit what we can do with it?
For the workloads ClickHouse is designed for — event capture, log ingestion, metrics, user behaviour, IoT telemetry — it is not a constraint, because those workloads are append-only by nature. A click event, a sensor reading or a log line is written once and read many times; there is no business reason to update the row. For workloads where row-level corrections are frequent and must apply immediately, Vertica's first-class UPDATE and DELETE under full ACID is the better fit. ClickHouse does support lightweight deletes and background mutations for exceptional correction needs, but those operations are asynchronous — changes are not immediately visible in query results while the background rewrite completes. Understanding which pattern dominates the workload is the first question in the engine selection conversation; the platform supports both patterns on the same deployment.
What the platform team covers on both engines
Deploying a columnar analytical engine alongside an operational application requires integration depth that generic BI consulting does not carry. The platform team covers the full operational lifecycle on both Vertica and ClickHouse — from first cluster to ongoing production.
Database setup and cluster configuration
Initial installation, cluster topology design, node sizing, storage layout, inter-node replication and resource-pool configuration — to production-grade standards, not a default install. Vertica single-node to multi-node MPP cluster; ClickHouse single-node to sharded replicated cluster with ZooKeeper or ClickHouse Keeper coordination. The same engineering team that runs these engines in production sets them up.
Data ingestion and pipeline design
Design and implementation of the feeds that move data from operational sources to the analytical tier. Batch loads, scheduled refreshes and streaming ingestion — sized and structured to the volume and freshness requirements of the workload, not to a generic template.
CDC — Change Data Capture from OLTP sources
Real-time capture of operational data changes — inserts, updates and deletes — from the OLTP database log, delivered to the analytical tier without polling or full-table scans. The operational application runs without modification; the analytical engine receives a continuous stream of changes and stays current without manual refresh jobs.
Query optimisation and ongoing operations
Query plan analysis, projection and sort-key design (Vertica), MergeTree and primary-index configuration (ClickHouse), resource-pool management and index tuning. Monitoring, alerting and incident response handled by the same engineers who built and run the platform.