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.
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.
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 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.
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.
The reporting plane answers questions of unlimited size: rows are held in memory-mapped files on the server, grouped and subtotalled, and scrolled without ever being resident in the browser. That is the right shape for a register nobody edits. It is the wrong shape for a question that changes every thirty seconds. The analytical grid is the other half — a bounded result set handed to the client precisely so it can be operated there.
A report can stream more rows than any browser could hold, because the rows stay on the server. An analytical grid is deliberately bounded and delivered whole, so that filtering, ranking, measuring and re-shaping happen in memory. No round trip, no re-query, no waiting between one question and the next.
Ask a column what it contains and it answers: valid, unique and empty counts; minimum, maximum, mean, median, standard deviation, mode, interquartile range and sum; the distribution as a histogram and a box plot; and the most frequent values with their repetitions and share of the set.
Each column filters three ways — matching text, a numeric range, or a list of its distinct values with the number of appearances beside each one. Filters compose across columns and reset per column. The result narrows as fast as it can be redrawn.
Colour a column by value and magnitude becomes legible down the column without reading a single number. Outliers surface where they are, in place, rather than after a sort.
Columns arrive already classified into measures and dimensions. Switch the view and the grid becomes a chart built from that classification — bar, line, area, box plot, pie, radar and their stacked variants — over the same rows, with the record and category count still on screen. Grid, cards, tree, kanban, calendar, gantt, timeline and map are the same set seen differently.
Every screen below is the same result set, held in the browser. Nothing between them is a new query.
The reports the operation depends on every day. Not dashboards — reports, with the rigour and audit trail enterprise operations require.
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.
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.
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.
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.
Grouped, subtotalled at every level, and traceable — every value in the left-hand columns is a link back to the records behind it.
Reconstructing a figure to its source is a property of the platform, not a feature added to one report at a time.
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.
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.
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.
Every drill-through is logged. Who looked at what, when, from where. The exploratory analytics surface is itself audit-grade.
The same period seen at three depths. Each screen is reached by clicking a value on the one before it, and the filters travel with the click.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
Invoices, statements, delivery notes, payslips, dunning letters. The reader is outside your organisation, the layout carries your name, and it has to be right every time.
The layout is authored once and rendered per record. A thousand invoices are a thousand renders of one definition, not a thousand documents to maintain.
PDF for archive, XLSX for a finance team that will re-cut it, CSV for a system that will parse it, HTML for an email body. The channel is a runtime parameter, not a second design.
Month-end runs, dunning cycles, a document produced the moment an order is confirmed. Output is routed by email, deposited on storage or surfaced in the application by the same runtime.
The document is produced by the platform against the user's own permissions. Nothing is exported to a rendering service, and the audit trail records who generated what.
Statutory filings, audit packs, technical publications, anything a regulator or a printer will measure. Margins, page masters, running heads and pagination are specified, not suggested.
Page geometry is declared — master pages, margins to the millimetre, recto and verso differences, bleed where the printer needs it. The same definition renders identically on every run.
Fonts, sizes, leading, rules, table shading, running heads and folios. The output is a print artefact, not a screen capture of a report viewer.
Content flows across pages with headers, footers and continuation rules intact. Tables carry their headings forward; totals land where the reader expects them.
The definition is server-side script in the metadata repository — diffable, promotable between environments, and covered by the same audit trail as everything else the platform runs.
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.
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.
| 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 |
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.
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.
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.
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.
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.
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.
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.
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.
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 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.