How ERGO Hestia reduced time-to-market with Lakebase and Mosaic AI Model Serving

How ERGO Hestia reduced time-to-market with Lakebase and Mosaic AI Model Serving | Databricks Blog Skip to main content

Summary

ERGO Hestia modernized its real-time pricing engine with Databricks Lakebase and Mosaic AI Model Serving, bringing data, features, and decisions into one lakehouse-native platform for millisecond pricing.

With increased scale, a multi hop architecture with an external PostgreSQL database and custom adapter layer created extraction overhead and fragmented governance across systems, slowing innovation in a regulated environment.

ERGO Hestia now ships new pricing models to production faster, enables the pricing team to respond instantly to market conditions, and proves every decision end-to-end via Unity Catalog — turning pricing into a strategic growth engine, not an IT bottleneck.

Building the Next Generation of Real-Time Pricing ERGO Hestia, one of Poland's leading insurance companies, operates a large-scale pricing platform supporting over 100 models and 1,000 variables. As one of Databricks' largest Polish users, ERGO Hestia has built substantial capability in state-of-the-art millisecond pricing and industry-leading execution speed. However, because the team is constantly pursuing the next great innovation in insurance technology, they recognized an opportunity to further maximize revenue by introducing real-time B2C capabilities. While the existing architecture was highly functional, the shift toward continuous model updates and instant customer responsiveness revealed a new challenge: sustaining innovation velocity as complexity scaled. The team had mastered the art of competitive pricing and was now ready to pioneer the next generation of real-time pricing delivery. Building on a close and productive partnership, ERGO Hestia and Databricks jointly discussed how to enhance the previous architecture for the next generation of real time pricing. This great collaboration led to the evolution of the platform using Lakebase to provide an Online Feature Store alongside Mosaic AI Model Serving Endpoints to keep all data and logic within the Databricks ecosystem. This architecture keeps both data and model serving inside the lakehouse, eliminating external systems and reducing model deployment time By unifying governance via Unity Catalog the team integrates data and model management to ensure full traceability and long term retention of historical training sets and model versions. This architecture provides Pricing experts with a reliable audit trail to ensure every decision remains fully traceable and verifiable while maintaining peak model performance. Ultimately this transformation positions the team to accelerate innovation velocity and respond rapidly to market conditions while continuously advancing their state of the art pricing models. The Challenge: Scaling Velocity Without Scaling Friction The previous architecture followed a logical pattern where Databricks ingested and transformed pricing data through its medallion architecture, then exported processed datasets to an external Azure PostgreSQL database. An intermediate adapter layer handled caching and exposed data to the pricing engine. This worked well when throughput was moderate. Yet as data volume grew and model iteration accelerated, the multi-hop pattern by moving data out of the lakehouse, through an external database, through a caching layer, to the application, began to constrain performance and agility. Operational Complexity: Maintaining an external database and a custom adapter layer created significant operational overhead as the massive maintenance burden of extraction jobs emerged as the primary challenge for such critical use cases. Additionally dealing with fragmented data governance across systems including Databricks for data processing and PostgreSQL for production serving as well as custom application code to handle request logic and integration meant that lineage tracking became challenging so that compliance and auditability suffered. Model Deployment Velocity: The previous multi-hop architecture required careful synchronization between model logic and the underlying serving infrastructure which created a technical dependency on coordinated deployment windows. While the team already possessed the pricing expertise to iterate quickly, the complexity of the external database and adapter layer meant that updates were often scheduled for off-peak hours to ensure system stability. This specialized orchestration limited the frequency of updates during the business day to avoid performance risks in the external adapter layer. Data Freshness Bottleneck: Large data ingestions created performance constraints that required careful orchestration to avoid impacting operating hours. Specifically, these updates often triggered 10x to 20x latency spikes in the external serving layer, which effectively restricted data refreshes to timed batch windows. To support the strategic move toward real-time B2C pricing, the team needed an architecture that could deliver continuous data availability throughout the day without these operational trade-offs.

For an organization managing 100+ models across 1,000+ variables in a regulated industry, this fragmentation created both operational friction and governance risk. The Solution: Consolidation within the lakehouse ERGO Hestia's transformation was built on three core technical pillars that unified all operations within the lakehouse. Lakebase for Unified Data Serving . Databricks Lakebase provides a relational transactional layer directly on top of Delta tables. By using Sync Tables, the team enabled continuous, automatic synchronization between processed data and the serving layer. This eliminated the need for manual orchestration and external extraction jobs. The result is a single source of truth for pricing data , living within the lakehouse. Model Serving Endpoints for Direct API Access . Rather than routing through an intermediate application with a separate caching layer and external database the Model Serving Endpoints expose data directly to the Pricing Engine application. This eliminates the adapter layer entirely and ensures that the request logic is kept natively within Databricks . Requests flow from the pricing engine to the Model Serving Endpoints and back in milliseconds to simplify the architecture by consolidating the query execution and data serving into a single managed layer. Model Serving for...