Modernise. Build. Operate. With the engineers who write the platform.
Seven product-adjacent service lines, all anchored to the Airtool platform — from OLTP modernisation to architecture audit, with an honest database competence map in between. Named deliverables, named team profiles, named engagement windows. Public commitments. Held to.
Anchored to the platform
Every service line attaches to Airtool. No service line stands alone of the platform. Engagements compound.
Product-adjacent engineering
The engineers we send are the engineers who write the platform. The codebase is the same codebase. The accountability is the same accountability.
Named deliverables
Discovery within 48 hours. Assess deliverable in four weeks. Design in twelve. Pilot in one quarter. Public commitments. Held to.
Honest competence
We declare in writing what we are good at and what we are not. The database tier table below is the example. Most consultancies don't.
Seven service lines
Each with deliverables, team profile and engagement window. Read the tile, then ask the question.
OLTP modernisation programmes
Replace Informix 4GL, Oracle Forms, Delphi, PowerBuilder, custom J2EE and bespoke ERPs on Airtool. Schema-first, database-business-logic-preserved, metadata-generated UI. Pilot in one quarter; programme in 9–18 months.
OLAP and analytics build-out
Vertica, ClickHouse or BigQuery for high-throughput columnar analytics; PostgreSQL or any of the platform's other OLTP engines where the workload fits. OLTP and OLAP under one roof, one runtime, one security perimeter. Audit, pilot, production. 6–12 months.
Database engineering
DBA-grade on Postgres, Informix, Vertica, ClickHouse (Tier 1). Development on MySQL, SQL Server, SAP HANA, Oracle, DB2 (Tier 2). Schema design, performance tuning, partitioning strategy, replication architecture, query optimisation, migration projects. Project-based engagements with discrete deliverables — ongoing operations live in the SRE service line below.
Custom application engineering on Airtool
Bespoke applications on the platform's metadata model and standard library. For customers who don't fit Airtool Apps but want the platform's economics, observability and AI posture. 12 weeks to 9 months.
AI and MCP integration
Multi-provider chat, RAG over the customer's choice of vector store (Qdrant, Milvus, PostgreSQL pgvector, Redis), governed SQL agents, MCP server with role-bounded tool access, AI-spend dashboards. AI assistants that operate inside the customer's permission perimeter, not above it. Audit → pilot → governed production, 4–6 months.
Platform operations and SRE
We run Airtool in customer environments. Database monitoring (slow queries, replication lag, deadlocks, table bloat) and backup supervision (success / failure, retention windows, restore drills) sit at the top of the operations stack. JMX and JFR feed the customer's existing APM and profiling tooling. Capacity planning, release management, replica failover, on-call. The first ninety days onboard the operation — installation, integration with the customer's monitoring stack, runbook authoring, backup-restore drill, SLA agreement. From month four, continuous managed service under agreed SLAs.
Architecture audit and advisory
Independent technical review of an existing data tier, application architecture, security posture or modernisation plan. A written report graded for a CIO or board memo. 4–8 weeks fixed-price.
The honest database competence map
Most database consultancies claim every engine. Their websites read like vendor logos pasted on a wall. The honest answer to the question of what they are actually deep on is rarely on the page, and a prospective customer usually finds out only after signing.
We do this differently. The matrix below states, in writing, where we offer DBA-grade engineering and where we offer development services only. Postgres is listed first by deliberate signal — modern, open, default. Informix is second because it is our deepest engine. Vertica and ClickHouse are the analytical heavyweights. MySQL, SQL Server, SAP HANA, Oracle and DB2 are engines we develop against fluently, without offering DBA-grade operations on them.
Database engineering — what we offer, by engine
| Tier 1 · Full DBA + Development | Tier 2 · Development only | |
|---|---|---|
| Engines | ✓ PostgreSQL · Informix · Vertica · ClickHouse | MySQL · SQL Server · SAP HANA · Oracle · DB2 |
| Performance tuning | ✓ Yes — partitioning, query rewrites, index strategy | No — refer to vendor or partner |
| Replication and HA | ✓ Yes — primary/standby, MPP, CDC, logical replication, failover | No — refer to vendor or partner |
| Backup and recovery | ✓ Yes — strategies, drills, point-in-time recovery | No — refer to vendor or partner |
| Capacity planning | ✓ Yes — modelling, sizing, growth projection | No — refer to vendor or partner |
| Incident response | ✓ Yes — retainer, on-call rota, post-mortems | No — refer to vendor or partner |
| Schema design and migration | ✓ Yes — multi-engine, with schema-evolution discipline | Yes — for application contexts |
| Application development | ✓ Yes — full stack, integrated with Airtool | Yes — full stack, integrated with Airtool |
OLTP and OLAP under one roof
The split between transactional and analytical systems is, for most enterprises, an artefact of tooling rather than a deliberate architectural choice. The OLTP team uses one set of vendors; the analytics team uses another. The data is copied between them. The security perimeters do not match. The AI agents that read the analytical store cannot write back into the operational one safely.
Airtool collapses the split. The same platform hosts the operational application surface and the analytical one — the OLTP application runs on one of seven supported engines (PostgreSQL, Informix, Oracle, DB2, SQL Server, MySQL or SAP HANA); OLAP workloads route to one of three analytical engines (Vertica, ClickHouse or BigQuery). Native SQL generation across both clusters — engine-native, not a generic dialect the engine has to translate. Authentication, audit, MCP and AI governance apply equally to both. The build-out service line stands up that integrated reality for the customer, in production, with the engineering team that wrote the runtime.
Engagement model
Four phases. Named, gated, predictable.
1 · Assess
One to four weeks, fixed-price. A focused engagement that produces a written deliverable. Everything else flows from it.
2 · Design
Four to twelve weeks, fixed-price. Target architecture, scoping, dependency map, risk register, programme plan.
3 · Deliver
Variable. Time-and-materials or fixed-price by phase. Pilot first, programme second. Incremental cut-overs by default.
4 · Operate
Ongoing. Retainer, on-call rota or managed-service contract. The team that delivered the programme runs it afterwards.
What buyers ask before they engage a service line.
Who actually delivers the engagement — partners or your own engineers?
The engineers who write the platform deliver the engagement. There is no third-party delivery layer between the customer and the people who maintain the runtime, the schema-code processor, the AI integration surface and the standard library. The codebase is the same codebase ; the accountability is the same accountability.
What engagement windows do you actually commit to?
Public commitments, held to : discovery within 48 hours of the first conversation, an assess deliverable within four weeks, a design within twelve weeks, a pilot within one quarter. Programme duration varies by service line — OLTP modernisation 9 to 18 months, OLAP build-out 6 to 12 months, AI and MCP integration 4 to 6 months, custom application engineering 12 weeks to 9 months, architecture audit 4 to 8 weeks fixed price.
Why declare a Tier 1 / Tier 2 database competence map publicly?
Because the alternative is asking the customer to discover it after signing. Most database consultancies claim every engine. The honest answer to "what are you actually deep on" is rarely on the page. Tier 1 — PostgreSQL, Informix, Vertica, ClickHouse — is where the team offers full DBA-grade operations. Tier 2 — MySQL, SQL Server, SAP HANA, Oracle, DB2 — is where the team offers fluent application development without DBA-grade operations. The split is on the page because the alternative is not honest.
Can we engage a service line without licensing the platform?
No. Every service line attaches to Airtool by design. Engagements compound because the runtime is shared : modernisation, OLAP build-out, custom application engineering, AI integration, SRE and architecture audit all operate against the same metadata model, the same supervised runtime and the same observability surface. Service lines without the platform underneath are not on offer.
What does Platform Operations / SRE actually cover?
Database monitoring (slow queries, replication lag, deadlocks, table bloat), backup supervision (success / failure, retention windows, restore drills), JMX and JFR feeds into the customer's existing APM and profiling tooling, capacity planning, release management, replica failover, on-call rota. The first ninety days onboard the operation — installation, monitoring integration, runbook authoring, backup-restore drill, SLA agreement — and from month four the engagement is continuous managed service under agreed SLAs.
What does an architecture audit produce?
A written report graded for a CIO or board memo, covering the existing data tier, application architecture, security posture or modernisation plan as scoped at engagement start. The audit is independent of any subsequent service line — customers commission audits without committing to the build that may follow. 4 to 8 weeks fixed price ; the deliverable is the document, not a slide deck.