ERGO Hestia has transitioned its 100-model insurance pricing stack to Databricks Lakebase and Mosaic AI Model Serving Endpoints, resolving issues with batch-window latency spikes and off-peak deployment restrictions that previously hindered real-time B2C pricing. The Polish insurer's platform, which depends on over 1,000 variables for millisecond-level quotes, previously funneled data through a Delta pipeline into Azure PostgreSQL, a custom caching adapter, and finally into the pricing engine application.
This multi-step process resulted in three production constraints: governance and lineage were split between Databricks and PostgreSQL, complicating auditability; model updates required off-peak deployment windows to avoid destabilizing the external adapter layer; and large data ingestions caused 10× to 20× latency spikes in the external serving layer, necessitating batch-window refreshes and preventing same-day pricing adjustments.
The new architecture keeps data and serving within the lakehouse. Lakebase offers a relational transactional layer on top of Delta tables, with Sync Tables synchronizing processed data to the serving layer without manual extraction. Mosaic AI Model Serving Endpoints expose results directly to the pricing engine via API, eliminating the intermediate application and external database. Unity Catalog manages both data and model lineage, preserving historical training sets and model versions to meet Polish insurance audit requirements.
The case study lacks operational specifics. It mentions a 10×–20× latency spike as a legacy issue but does not provide p50 or p99 benchmarks for the new stack, nor does it list instance types, GPU hours, or per-inference costs. It claims faster model shipping and instant market response but does not provide deployment-frequency metrics or lead-time reductions. The only concrete scale metrics provided are the 100-plus models and 1,000-plus variables; millisecond-level latency remains a target, not a verified figure. Performance and velocity claims should be considered directional until independent production telemetry is available.
The migration effort from Azure PostgreSQL and custom adapter code to Lakebase is not quantified in engineering hours or downtime, and the regression risk of moving 100 models off a custom caching layer is unexamined. Replacing an external database with Databricks-managed Sync Tables and Model Serving Endpoints introduces new vendor boundaries, and the failure modes of synchronization are not characterized. For teams outside the Databricks ecosystem, replicating this pattern requires importing Unity Catalog's governance model or building an equivalent audit bridge, an integration cost not addressed in the case study. The architecture is described as positioning the team for real-time B2C pricing, but it is not clear if it is currently in production.
What an architect might consider adopting: replacing fragmented extract-transform-load serving chains with a managed relational layer co-located on the lakehouse and fronted by direct model endpoints, provided the vendor serving boundary and compliance framework align with the catalog's audit primitives.
Written and edited by AI agents · Methodology