The Data Platform in 2026: Lakehouse, Legacy, and AI Agents

The first boundary separates operational and analytical work. An OLTP system favors short concurrent operations and point reads with millisecond latency, while analytics scans large volumes and joins datasets. The guests offer a concrete reference: in TPC-H on Postgres, two of twenty queries failed to finish within an hour on tables of up to one hundred million rows. At some point, analytical growth therefore requires a specialized engine rather than merely a larger server. This result is not a universal database threshold; schema, hardware, and tuning all matter. It demonstrates the qualitative difference between workloads and the point where vertical scaling stops answering the architectural problem.

A classic MPP warehouse works well up to a certain scale, but coupled storage and compute impose limits. One slow node delays a distributed query, concurrent users complicate isolation and quality of service, and cluster growth requires repartitioning all data. The guests cite roughly 20–30 nodes as the range beyond which operating costs climb quickly. Modern networks, compression, and column pruning made remote object storage practical and opened the way to separating storage from compute. Separation lets teams scale resources independently and isolate workload profiles, but moves complexity into networking, metadata, and component consistency. The architecture changes constraints rather than eliminating them.

A minimal lakehouse combines S3-compatible storage, Iceberg as the table and transaction layer, a metadata catalog, compute, and access control. Real load introduces retries, concurrent writes, compaction, orphan files, component compatibility, and thousands of S3 range requests. Trino still carries MPP fan-out and sensitivity to storage latency. Tengri takes another approach: lightweight isolated compute can start for a session, a query-aware cache speeds repeated reads, and heavy queries receive parallelism when needed. A component list is not yet a platform. The operating product also needs table maintenance, observability, access policy, and tested version compatibility; otherwise one failing background process gradually degrades the whole system.

Legacy migration is measured in years, not an endpoint switch. In one example, a move from Vertica began in 2022; four years later most workload runs outside the old MPP system, but a long tail remains. Accumulated transformations and stored procedures deepen lock-in—one presale involved two million lines. A year of selling Tengri produced another lesson: a platform does not sell value by itself. It must connect to forecasting, pricing, recommendations, or another measurable business outcome. The tail persists because code embodies years of implicit rules and consumer dependencies. A realistic plan covers parallel operation, result reconciliation, and retirement criteria for each slice rather than only table-transfer speed.

Natural-language analytics needs more than SQL access. An agent requires a semantic layer and deterministic checks for common failures: a wrong filter or a join that silently multiplies rows. Tengri already has Theodore, which answers data questions, and Dasha, which builds dashboards. They can clarify a business question, inspect tables, and run validation queries, but a convenient interface does not remove the requirement for a correct result. Semantics connects a business concept to fields, time, and valid aggregation; without it, syntactically correct SQL can answer a different question. Verification must cover the meaning of the returned dataset, not merely query execution.

According to Nikolay, an analyst with an agent generates about five times as many queries, including Cartesian products of huge tables and even destructive SQL. Permissions must truly block forbidden actions, while isolation must prevent one query from taking down a department or executive dashboards. Tengri's harness checks that an agent executed its SQL, read the result, and used only allowed operations. Fixed dashboards will remain because a human must still be accountable for a verifiable result. Higher query volume turns a rare mistake into a recurring operating threat. Resource budgets, read-only access, and time limits must trigger automatically because manual control cannot keep pace with generation.