Workload matters more than an architecture label
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.
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.
A lakehouse is a system, not a box of parts
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.
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.
AI agents raise the bar for the foundation
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.
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.
What to take away
- 01Separate OLTP from OLAP when representative analytical queries reach the operational database's limits, not merely to adopt a fashionable stack.
- 02A lakehouse separates storage and compute while moving complexity into integration, transactions, catalogs, caching, compaction, and S3 operations.
- 03MPP migration takes years: assess the legacy tail, stored procedures, and connection between the new platform and a measurable business outcome.
- 04AI agents multiply workload and failure risk, so they need semantics, strict permissions, isolation, and deterministic execution checks.
Sources
- Local Whisper transcript of the Podster audio edition
- Episode recording on YouTube