Skip to content
Data This Week
Go Back

Data This Week #30

7 min read
On this page

Welcome back to Data This Week!

This week’s edition covers critical shifts across database ownership, AI context layers, and production data pipelines. From Amazon’s blockbuster acquisition of DuckDB Labs to AngelList’s contrarian approach to building a self-updating semantic layer with Markdown and GitHub Actions, data architectures are rapidly adapting to an agentic future. We also look at managing runaway agent token bills at Databricks, low-latency streaming in AWS Glue 6.0, Polars hitting its 2.0 release candidate, and practical advice from the trenches on migrating legacy on-prem databases without rebuilding the wheel.

Here are the top reads, tools, and community discussions for senior data folks this week.

📚 Blogs to Read

DuckDB Outgrows Its Nest: Amazon Acquires DuckDB Labs

In massive news for the analytical database ecosystem, DuckDB Labs — the core engineering team behind DuckDB — has been acquired by Amazon. Writing on the MotherDuck blog, CEO Jordan Tigani breaks down the implications for the community, why the open-source MIT license remains safely protected under the independent DuckDB Foundation, and what this signals for cloud data warehousing. Tigani argues this move follows Amazon’s classic playbook of validating battle-tested open source before building fully managed services, setting the stage for healthy enterprise competition alongside Redshift and MotherDuck.

Read more →


The Semantic Layer Nobody Maintains

While modern data stack vendors push centralised semantic layer engines (like dbt MetricFlow or Snowflake Semantic Views) behind paid runtime tiers, AngelList took a completely contrarian architectural route. Recognising that the primary consumer of metrics is now an AI agent, they ditched complex query-planning DSLs for plain Markdown knowledge files and procedural skills stored in their dbt repository. The killer feature: automated GitHub Actions and Python scripts parse manifest.json, mine upstream Rails/Prisma application codebases, and aggregate Snowflake query telemetry on every merge — producing a 100% self-updating semantic layer that never goes stale.

Read more →


Managing AI Coding Costs at Scale

While coding agents have driven order-of-magnitude velocity gains, engineering organisations running them at scale have hit an exponential cost wall. Databricks engineering outlines how they and peers like Stripe, Uber, and Ramp reconciled this spend without throttling developer output. Instead of rigid token caps, they leverage the efficiency frontier (evaluating and shifting workloads to cheaper models), dynamic request-level routing via Unity AI Gateway (achieving ~30% cost reductions), client-side meta-harnesses like Omnigent, and transparent self-clearing spend gates.

Read more →


Federated Data Access Patterns for AI Agents

Data engineers spend countless hours fielding ad-hoc tickets across disparate systems: Athena/S3 batch data, Kinesis streams, and operational relational stores. The AWS Big Data Blog outlines an agentic architecture pattern using the Model Context Protocol (MCP) and Amazon Bedrock AgentCore. Instead of forcing all data into a unified lake or maintaining fragile bespoke pipelines, lightweight MCP servers wrap heterogeneous storage engines into standardised tool interfaces — allowing agents to securely negotiate and query federation layers on the fly.

Read more →


The Power BI Developer’s Survival Guide to Microsoft Fabric

With Microsoft sunsetting Power BI Premium P SKUs and shifting the ecosystem entirely toward Fabric capacity (F SKUs), BI teams are caught between fear of obsolescence and platform hype. Nikola Ilic delivers a pragmatic breakdown of what senior BI and data platform engineers actually need to know: core modelling (DAX, Power Query) remains unchanged, but the emergence of OneLake and Delta format unlocks Direct Lake mode — bypassing traditional Import/DirectQuery refresh trade-offs. The post separates critical migration steps from architectural distractions you can safely ignore.

Read more →


Decoding Customer Value: pLTV Models for India’s Quick Commerce Delivery Wars

Predicting customer lifetime value (pLTV) before a user even places their first order is critical for acquisition bidding, but zero-inflated distributions and coupon-churners break traditional regression models. Swiggy’s data science team shares the architecture behind their production pLTV system: combining 350+ multi-scale spatial and behavioural signals (from Geohash-8 apartment density to phonetic address matching) with a compact 4-head MLP architecture. Adding auxiliary order-frequency tasks acted as free regularisation, slashing model parameter size by 63% while matching commercial third-party bidding platforms.

Read more →


Real-Time Event Pipelines with Spark Real-Time Mode on AWS Glue 6.0

Handling high-throughput, multi-schema event streams often creates an ugly trade-off: rigid, sparse schemas versus scanning terabytes of costly raw JSON blobs. AWS Glue 6.0 introduces Apache Spark 4.1 under the hood, featuring Spark Real-Time Mode (RTM) to eliminate micro-batch latency down to sub-second levels, native Apache Iceberg v3 integration, Variant data types with automatic shredding, and Arrow-native UDFs. This post walks through an end-to-end market risk pipeline that simultaneously enables sub-second alerting and ultra-fast batch VaR computations.

Read more →


Pre-Release of Polars 2.0: Streaming Engine as Default

The Polars team announced the release candidate for Polars 2.0. The team aims for this major version bump to be an intentionally “boring” transition with significant performance dividends. The headline change: all LazyFrame queries now default to the streaming engine rather than in-memory execution, yielding up to 5x faster speeds and substantially lower memory footprints (note: operations like join and group_by no longer guarantee row order by default without explicit flags). Version 2.0 also tightens safety with strict type-coercion and shape checks to fail early on subtle bugs.

Read more →


🛠️ Tools

OpenCode (Adding Free Meta Muse Spark 1.3 via OpenCode Zen)

What it is: OpenCode, an open-source terminal-based AI coding assistant and agent environment, announced that Meta’s newly released coding foundation model, Muse Spark 1.3, is now accessible for free via the OpenCode Zen gateway (muse-spark-1.3-contributor-free). For data and platform engineers seeking a high-context terminal companion for long-horizon refactors and repo-wide exploration without locking into proprietary IDEs, it provides granular reasoning effort variants (low, medium, high, xhigh) straight from the CLI.

Announcement on X →


💬 Community Sentiments

Extracting Data from Legacy On-Prem Databases: Don’t Over-Engineer Day One

A lively thread on r/dataengineering tackled a familiar pain point: modernising pipelines out of legacy on-prem databases (SQL Server, Oracle, Postgres) into cloud data lakes (ADLS/Databricks) without letting brittle Azure Data Factory (ADF) pipelines hold the team hostage.

Senior practitioners weighed in with a strong consensus against “code-first extremism”:

  • Keep Extraction and Transformation Decoupled: Several engineers pointed out that ADF’s main weakness is being misused for complex data transformations (via GUI dataflows). The pragmatic fix is to demote ADF/Self-Hosted Integration Runtime (SHIR) to a “dumb pipe” extractor that dumps raw Parquet onto object storage, letting Databricks and Unity Catalog handle orchestration and heavy lifting.
  • Network Drives the Architecture: If ExpressRoute or private VPNs exist, Databricks Lakeflow Connect or native JDBC tasks suffice. If the network path is restricted outbound on 443, containerised self-hosted tools running on-prem (like Airbyte or lightweight Python dlt taps) avoid building custom, state-heavy CDC offset managers from scratch.
  • The SRE Warning: Replacing working extractors with self-managed Airflow clusters or custom scripts introduces hidden operational overhead (secrets rotation, driver patching, schema drift) that legacy client teams rarely have the appetite to babysit.

Join the discussion on Reddit →


That’s all for this week! See you in the next edition.


Keep reading