This episode is useful because it grounds the data-platform conversation in real questions about centralization, federation, Data Mesh, and the boundaries between OLTP, MPP, and platform services instead of hype alone.
In day-to-day engineering work, it helps translate 2025 market ideas into a capability map and concrete architecture decisions rather than another tool list the team will spend years supporting.
In interviews and architecture discussions, it is especially strong when you need to surface tool sprawl, vendor lock-in, and platform cost growing faster than real value.
Practical value of this chapter
Design in practice
Translates 2025 market trends into actionable architecture choices for data-platform teams.
Decision quality
Evaluates platform maturity through capability maps rather than tool checklists.
Interview articulation
Adds current context for discussing the modern data stack, governance, and cost control.
Risk and trade-offs
Highlights tool sprawl, vendor lock-in, and uncontrolled platform-cost risk.
Data platforms in 2025: interview with Nikolay Golov
An interview about how a data platform actually lives in practice, not on a diagram: operating models, platform as a product, where OLTP/MPP hit their limits, and how to roll all of this out without creating organizational chaos.
Source
Telegram: Book Cube
A short summary and the key points from the episode in a single post.
About the episode
The core question in this interview is practical: how to build a data platform that accelerates product teams instead of slowing them down. What decides it is not the choice of technology but the balance between domain autonomy, shared platform standards, and cost control.
The takeaway is blunt: arguments about “the perfect stack” usually lead nowhere. In 2025 a platform succeeds or fails on its operating model, ownership, and the quality of its capabilities — none of which you buy in one purchase.
Guest and context
Nikolay Golov
- Head of Data Engineering at ManyChat.
- Ex Head of Data Platform at Avito.
- Data platform practitioner and database educator.
The value of this episode is that organizational decisions and architecture trade-offs are worked through together rather than separately — in practice it is the gap between them that breaks platforms.
What changed in 2025
- The storage-engine debate moved to the background; what decides now is the platform operating model — who owns what and how teams get data.
- There are more data products, and that cuts both ways: demand for self-service grew, but the cost of weak governance is now visible immediately.
- Separating storage from compute and using open table formats stopped being an experiment — without them, a platform proposal is no longer taken seriously.
- LLM and low-latency use cases raised the bar: stale data and opaque pipelines now reach the product faster than anyone notices.
- Data-platform economics, together with FinOps practices, became as much of an architectural constraint as latency and reliability.
Related chapter
T-Bank data platform overview
A practical case: how a data platform moves from a classic warehouse (DWH) to a lakehouse architecture.
Data-platform operating models
Centralized platform team
Best fit: Early stage companies or organizations with a limited number of domains.
Strengths
- Standards for quality, security, and tooling are held consistent by one team.
- Core platform capabilities ship fast, without long cross-domain negotiation.
Risks
- Domain requests funnel through one team, and that team becomes the bottleneck.
- Product teams barely own source-data quality — the platform does it for them.
Hybrid model (platform + domain squads)
Best fit: Mid-size and large companies with multiple products and different data SLAs.
Strengths
- The platform team builds shared capabilities while domains own their data products and answer for them.
- Time-to-data drops without losing standards or cost control.
Risks
- Needs explicit ownership boundaries and interface contracts — otherwise responsibility blurs.
- Loosen governance and quality, schemas, and semantics start to diverge across domains.
Federated model (mature Data Mesh)
Best fit: Very large organizations with highly autonomous domain units.
Strengths
- Domains move at full speed and own the outcome on their side.
- Ownership scales without routing every decision through the center.
Risks
- Without a shared quality bar, the mesh becomes a set of fragmented local solutions instead of a mesh.
- If shared platform capabilities are underinvested, coordination cost across domains grows fast.
Reference architecture for a data platform
Ingestion and capture layer
Focus: CDC, event buses, batch connectors, and contract-based ingestion.
The job of this layer is predictable delivery into the platform while keeping schema and freshness under control. It is also where everything downstream breaks if ingestion is unstable.
Storage and table format layer
Focus: Object storage + open table formats (Iceberg/Delta/Hudi), partitioning, compaction.
This layer owns durability and schema evolution and separates compute from physical storage — you can swap the processing engine without touching the data itself.
Compute and transform layer
Focus: Batch/stream processing, dbt/SQL transforms, orchestration, and retries.
This is where domain-ready data marts come together and freshness targets are set. The cost of a mistake here is a non-reproducible pipeline that returns a different result on the next run.
Serving and consumption layer
Focus: BI, reverse ETL, feature stores, API access to data products, MPP serving.
The consumption layer balances self-service against control: let teams pull data themselves, but don't lose grip on query cost and access.
Governance and reliability layer
Focus: Catalog, lineage, data contracts, quality checks, observability, incident playbooks.
This layer is usually the first one cut for speed — and that is exactly when hidden debt builds up and business trust degrades. Rebuilding trust costs more than not losing it.
Common anti-patterns
Data Mesh without a real platform
Problem: Teams are declared autonomous but get no shared capabilities for contracts, quality, and discoverability. Autonomy without a foundation just turns into fragmentation.
Fix: Build the platform layer and a governance minimum first, then scale federation.
One MPP as the universal answer
Problem: MPP may cover part of OLAP serving, but it does not own ingestion reliability, contracts, or accountability for the result.
Fix: Treat MPP as one serving component inside a broader data platform, not as the platform itself.
Raw data without product ownership
Problem: No one owns the meaning of the data, so downstream teams build conflicting metrics on top of the same tables. The mismatch eventually surfaces in business reports.
Fix: Assign data product owners and publish explicit quality and freshness SLOs.
Technology-first, outcome-last
Problem: The stack gets modernized, but time-to-data for product teams stays the same. Modernization for its own sake does not justify itself to the business.
Fix: Tie every platform initiative to a business metric: lead time, reliability, or cost per query.
Patterns that consistently work
- Data contracts as mandatory interfaces between producer and consumer teams: change a schema and you don't silently break someone else's pipeline.
- Unified catalog and lineage so you can find dependencies and see what a change will break before it reaches consumers.
- Standardized Bronze/Silver/Gold layers plus a semantic layer give a predictable data flow instead of a pile of ad-hoc transforms.
- Product-oriented ownership with SLOs for freshness, completeness, and schema stability — every data product has an owner, not just an author.
- A FinOps loop for the data platform: compute budgeting, storage optimization, showback and chargeback so cost is visible to whoever creates it.
180-day implementation roadmap
Baseline and constraint map
Start with an inventory: sources, critical pipelines, current SLAs, SLOs, and incidents. Capture the architectural baseline and the constraints that actually block product teams, not the ones that sound good in a talk.
Minimum governance and shared interfaces
Introduce data contracts, a catalog, and basic quality checks for critical domains. This is also where you lock in schema evolution rules and ownership of data products, while there are few domains and agreement is still cheap.
Self-service capabilities
Launch reusable ingestion and transformation templates, observability standards, and repeatable pipeline setup. The goal of this stage is to cut time-to-first-dataset so teams stop queueing for the platform.
Economics and scaling the model
Enable showback and chargeback, optimize compute and storage, and expand domain ownership. By this point the hybrid operating model usually becomes the default.
Related chapter
Data Governance & Compliance
What keeps trust in the data: quality, lineage, and access-control practices.
Platform maturity metrics
Time-to-first-dataset
Target: < 1 week
How quickly a new use case gets production-ready data. When this grows, the platform is becoming the bottleneck.
Pipeline reliability
Target: 99.9%+
Share of successful critical pipeline runs without manual intervention. Anything fixed by hand overnight does not count here.
Freshness SLO compliance
Target: >= 95%
How often data meets declared freshness windows — whether the promised freshness can actually be trusted.
Schema incident rate
Target: Quarter-over-quarter reduction
How many incidents come from incompatible schema changes — a direct signal of whether data contracts are working.
Cost per successful insight
Target: Controlled downward trend
Links platform cost to real business value, not just to the compute bill.
Reusability ratio
Target: > 60%
Share of reusable data products and standardized pipelines. A low ratio means every team rebuilds its own from scratch.
Related materials and references
- YouTube: Data platforms 2025 - Full interview recording.
- Telegram: Book Cube - Short summary of the episode with key points.
- Yandex Music - Audio version of the podcast.
- Podster.fm - Alternative audio platform.
- T-Bank data platform overview - The same trade-offs on a real case: how the platform and its architecture changed over time.
- Data Mesh in Action - What sits behind the federated model: domain ownership, a self-service platform, and federated governance.
- Data Pipeline / ETL / ELT Architecture - How the ingestion, transform, and serving layers from this chapter are actually built.
- Data Governance & Compliance - The governance layer up close: data quality, lineage, and compliance.
- Apache Iceberg architecture - How open table formats give you a transactional layer on top of the lakehouse.
- ClickHouse - A fast analytical serving layer for data products on the consumption side.