Entrada

For most of the last decade, the goal of a data platform was simple: make the data available. Land it, govern it, and let the humans take it from there. That goal is no longer enough. In 2026, the consumer of your enterprise data is increasingly likely to be something other than a human. It […]

Mortgage lenders sit on rich data across CRM, LOS, and servicing systems, yet still struggle to identify which borrowers are about to transact. Entrada’s Mortgage Intelligence Platform addresses that gap with a Databricks-native architecture: Cotality property intelligence delivered through Delta Sharing and Unity Catalog, deterministic scoring as governed SQL primitives, Genie grounded in a curated semantic layer, and Lakebase Postgres recording every approval and audit event. The result is a governed lead generation layer that tells growth teams who to contact, why now, and with what offer – and proves it afterward.

After years of architecting ML platforms on Databricks, one pattern keeps repeating: the difference between a model that survives in production and one that quietly fails usually comes down to how features are managed. Here’s what we’ve learned the hard way.

Every serious governance project eventually reaches the same uncomfortable moment: the platform has the metadata, but the organization still does not have a product. There is a catalog. There are tags. There are comments, owners, lineage events, audit rows, dashboards, policies, and a dozen local rituals around who is allowed to change what. Yet when a steward asks, “Can I safely change this field?”, the answer still arrives as a meeting, a spreadsheet, and a prayer.

Inside the Customer Billing Accelerator from Entrada and Databricks, an agentic AI stack that detects anomalies, answers finance questions in plain English, and writes back to source systems, all governed through Unity Catalog.

A field report on what changed between DataPact 2.9 and 3.0, why we put a managed Genie space at the centre of the release, and the engineering it takes to make a conversational data quality surface trustworthy enough to call a product.

This post walks through the architecture Entrada built around that observation, the Serverless Cost Control Accelerator, and, more importantly, the design principles behind it. Regardless os whether we’re a platform engineer, SRE, or FinOps lead trying to decide where to invest, the principles matter more than the product.

Research organizations need faster, more reliable ways to prepare sensitive data for analysis without loosening their grip on governance and privacy. Across the medical research platforms we’ve built on Databricks, the same patterns keep proving their worth: cleaner ingestion, standardized de-identification, simpler access to research-ready datasets, and a foundation that holds up when analytics and AI ambitions grow. Here’s what we’ve learned about designing these environments well.

Every enterprise manages two separate, expensive database systems: OLTP for real-time transactions and OLAP for analytics. The pipeline connecting them is the most fragile thing in the entire stack. Databricks’ Lakebase makes that pipeline optional, offering a strategic opportunity to collapse two stacks into one and finally deliver the near-real-time data that critical business applications need.

Databricks is directionally right to push serverless. Its current guidance recommends serverless for supported workloads because it is the simplest, most reliable option for notebooks, jobs, and Lakeflow Spark Declarative Pipelines, and its compute selection guidance recommends serverless for most automated workloads while steering SQL tasks toward serverless SQL warehouses.