Building Enterprise KPI Platforms: Prada's 100x Speedup with Lakebase

Summary

Prada Group, with 8,000 employees across 70-plus countries including the recently incorporated Versace brand, built a unified KPI platform on Databricks Lakebase that standardized 4,000 KPIs into a single semantic layer with a unified taxonomy and millisecond-latency serving.
The architecture stores KPI taxonomy in Unity Catalog and enterprise entities in the lakehouse silver layer, with Databricks Lakebase providing Postgres-native serving for channel-agnostic APIs validated at 15-millisecond response times under concurrent load — a 100x improvement over their legacy system.
The video covers the KPI engine architecture, the online latency problem that Lakebase solved, load-testing methodology, and Prada's roadmap toward a full enterprise semantic ontology.

Building Enterprise KPI Platforms: Prada's 100x Speedup with Lakebase

Enterprises managing complex KPI landscapes face fragmentation across systems, inconsistent calculations, and latency. Prada Group, serving 8,000 employees across 70+ countries, built a unified KPI platform on Databricks Lakebase. They standardized 4,000 KPIs into a single semantic layer with unified taxonomy, calculation engine, and millisecond serving. Result: 100x faster response times versus their legacy system.
Learn Prada's architecture: taxonomy in Unity Catalog, enterprise entities in Lakehouse silver layer, Lakebase Postgres-native serving for channel-agnostic APIs. Andrea Carmè and Michele Piunti explain the KPI engine, the latency problem Lakebase solved, and testing that validated 15ms response times under concurrent load. Plus their roadmap toward enterprise semantic ontology.
🤝

Chapters

FAQs

What is Databricks Lakebase and how did Prada use it for their KPI platform?

Databricks Lakebase is a managed PostgreSQL-compatible serving layer within the Databricks Data and AI platform that provides low-latency transactional reads. Prada used it as the serving tier for their KPI platform, enabling channel-agnostic APIs to retrieve pre-computed business metrics at 15-millisecond latency without querying the analytical lakehouse directly.

What problem did Prada's unified KPI platform solve?

Prada's business units were calculating key performance indicators inconsistently across fragmented systems, leading to disagreements over metric values and latency that made real-time decision support impossible. The new platform standardized 4,000 KPIs under a unified taxonomy with a shared calculation engine, served at 15-millisecond response times through Lakebase.

What performance improvement did Prada achieve with their Lakebase KPI architecture?

Prada achieved 100x faster response times compared to their legacy system, with Databricks Lakebase delivering 15-millisecond responses validated under concurrent load testing. This level of performance enables real-time KPI access for the business applications and users across Prada's global operations in 70-plus countries.

What is the role of Unity Catalog in Prada's KPI platform?

Unity Catalog stores Prada's KPI taxonomy — the definitions, hierarchies, and governance metadata that describe what each of the 4,000 KPIs means and how it is calculated. Anchoring the taxonomy in Unity Catalog ensures all consuming applications and teams work from a single governed source of truth for metric definitions.

Full transcript

[00:09] Okay. Morning all. Thank you all for being here. Uh what you're going to talk now is our initiative. We are Prada Group Prada Group from Italy and the talk today is on how we introduce at
[00:25] introduced at the KPA framework enhancing its adoption inside the lake house using lake base providing this enterprise business metrics layer to our lake house.
[00:40] Uh me as a data platform manager and special product projects manager in Prada are governing the data platform which is basically on data bricks technologies. And this work and our
[00:57] data strategy is done in collaboration in collaboration with I Consulting and Andrea which here is with me and is dealing with the technical details and then solutioning details that we will discuss in this presentation in the second part
[01:13] of this presentation. So who we are? Does anybody don't know Prada? Maybe hopefully no. So
[01:31] So Prada is a big global player in uh in the realm of fashion and luxury. And uh the DNA of this maison is uh profoundly grounded on uh this uh
[01:46] creative approach which is 360. So not only related to fashion but most in general to this multi-disciplinary approaches to culture, art, sports, you
[02:01] know, sales, Luna Rossa, and so forth. So, it is not a group dealing only with fashion, but is in general a group dealing with a global trends for beautiful and a
[02:18] related luxury uh products in general. Uh These approaches very important behind our mission, which is somewhat rooted in the in the in the DNA of of the company. In
[02:37] some sense, Prada is pushing a lot on aspects which are related to uh exploration, curiosity, modernity in the overall. And these are not only, as they say, uh
[02:54] mhm slogans, but are operating principle at all the levels in uh in the enterprise. And not only in the manufacturing of products, but also in how we did in general things.
[03:09] Also digital things and data related things. So, we we put a lot of effort in doing our platform very carefully, focusing a lot on all the aspects, giving time to
[03:25] make the things to mature, to be perfect in the end, and somewhat reflecting this DNA. As a group, of course, we are a corporated group from uh the end of last year, we also
[03:41] incorporated Versace, which is another big Italian brand in in fashion. Uh we reach with Versace almost $7 billion this year. We count
[03:56] uh 8,000 head counts uh with uh 70, more than 70 countries uh worldwide, and operating stores that reach almost 1,000 in by counting directly operated
[04:13] store and also uh not directly operated stores. And also, we own a lot of facilities in the world. Globally spread in a retail sales force, which is open 24/7 in all the
[04:29] um main region in the world. In Europe with uh 245 stores. So, we have this uh need to spread our data products and our digital services uh everywhere in uh all the countries
[04:45] uh in all the operating sales force management team uh directly day-by-day, hour-by-hour. Uh With me, Andrea, which was uh at our side in the last years and helped a lot uh in doing our
[05:03] blueprint strategy, data strategy. And we began from scratch uh two or three years ago, maybe as soon as Unity Catalog was available, we suddenly tested how this may work for building a structured and semantically evolution of
[05:20] the normal data lake. And this was one of our principal results so far. So, Andrea. Yeah. So, um nice to meet you. I'm Andrea, I'm a senior manager within I Consulting. I Consulting is a consultant firm based uh
[05:36] in Italy. Uh we have been doing uh data and AI uh for about 25 years now. Okay. We started back um uh in 2001 uh from a research lab. And now we are 500 and more, uh, high highly
[05:54] specialized, uh, professional in the data and AI. So, what we do is to tackle, uh, data, uh, challenges. So, uh, I think that now we can introduce, uh, the challenge that we had within, uh, Prada and I pass the
[06:13] word again to Michele that we we he will introduce, uh, our challenge. So, let's focus on these initiative. Zoom in, okay? Our problem is somewhat make, uh, an enterprise framework, which
[06:29] contains what we call KPI. What is a KPI? Is a key performance indicator, basically. And, uh, slowly Prada began to use those KPI as a basic atomic unit of information.
[06:44] We at the end of the day become, uh, a pivotal piece of information of knowledge within our processes and which are very important for any kind of digital transformation inside the company. From the normal analytics, uh,
[07:01] to the, uh, marketing automation and client dealing processes that slowly are becoming more and more digital, more and more automated, more and more AI governance in some sense. So, for doing this, we need this basic brick of
[07:17] knowledge. I can mix you some example of for instance, what could be in the retail, uh, acception, a KPI. It could be the amount of sales, um, per day or per store, the number of, uh, private
[07:35] appointment scheduled by a sales assistant, uh, the redemption, uh, for a given customer, for a given client, in a given event, or the conversion occurred after a given event
[07:51] for a given customer in a given situation. So, those are all examples of what we call what we call KPI. And we have thousand and thousand of those KPIs. So, after an initial step,
[08:07] an initial phase of assessment, organizing these KPIs, which are spread over several offices, several digital assets, Excel files, database system, each using its own definition,
[08:24] each uses own function of calculation. We assessed all in a common glossary, which was spread and shared across the enterprise, and from that start point, we implemented it. But we, as a data platform owners, had additional
[08:42] challenges because it was not only a matter of organizing knowledge and make a glossary of them. Uh, but also we we had need to expose those KPI, uh, at scale, of course. So, not only for traditional dashboard, not
[08:59] only for analytic, uh, BI dashboards, but also for consumers that could be, you know, other data mesh teams, or agents, or data analysts, data scientists that day by day use these, uh,
[09:15] these, uh, concepts. So, we we had, uh, those several challenges all in one to deal with, and we were looking for a solution. At, you know, if I think 1 year ago, those solution was not obvious because our first idea
[09:32] is, "Okay, let's introduce some, uh, another external vendor solution, the so-called semantic layers. We have many. You have at scale cube to not make names, but No, there are
[09:47] many that you can cool want to use. But at the same time, we had the fortune to to encounter Lake Base during the way. And that was one opportunity that we had to to push.
[10:03] Before that, uh during the assessment phase, so we are organizing those KPIs in a few number of families. Which means give some semantic to the family of similar KPIs. So, KPI which in
[10:19] some sense can be related to some context and to some common knowledge behind. So, we can for instance in this in this example, you see the KPI for sales
[10:34] all the indicators which in some sense relate to the sales data. Or all the KPI, the above diagram diagram graph, which relates to customer engagement. Okay?
[10:49] And those based on those families, we can uh some sense drill down the those families based on core dimensions because each of those KPIs inside these supersets
[11:05] can also be seen as cut from core dimension as temporal dimension. So, you can see the KPI from the point of view of time unit, which is day, week, month, or year. Or from the point of view of the sales
[11:21] force of the retail sales force. For instance, you can see the KPI based on the brand or on the channel or on the on the store, and so forth. Obviously, more many of those KPIs are related to client
[11:39] to customers in the end. But also to products master data because, you know, as brand we we we had many products category, bags, shoes, ready-to-wear.
[11:58] Each of those category is characterized by proper condition, proper attributes, proper context. So, making this determination is fundamental for us. Okay? So, given this initial assessment, which is purely theoretic,
[12:13] the second step was focusing the model, the let me say the platform model for doing this. As I said, when we initially started to think about this platform, the first idea was to
[12:28] buy some external solution. But in the end, as we said in the beginning, we are manufacturer of things. And so, we decided that Databricks has all the capabilities to build a suitable
[12:45] solution, which was at that moment in our idea suitable for us for this solution. And at that moment in particular, Lake Base came out and was providing these characteristic
[13:02] of being super fast to being super scalable and to be very flexible in front of microservices definition because one of the characteristic of Lake Base is
[13:17] having an APA Postgres native layer. Okay? So, this was basically the idea behind our initial choice. Andrea will give you additional details for 1 2 3 the blocks and I'll let him.
[13:37] Thank you, Michele. Thank you very much. So, what we will do is to go under the hood and see each component one at a time. I'm going to start with the first step, the first
[13:52] layer, which is the foundation for us. Foundation means that we have a taxonomy and we have also the KPI KPI definition. So, both are within the Unity Catalog, so are
[14:08] governed in the same place as the data itself. This is an important step because we don't want that KPI definition are stored outside our platform.
[14:26] So, how we define how a KPI is defined. A KPI is defined mainly inside a YML file and each KPI has been defined within YML descriptor where we place the
[14:44] formula, the dimension, the filter and the time period. So, this is important because we have only one YML file that for us is the single version of truth for this KPI. It means that we define
[15:00] the logic one time and we don't have logic within, for example, notebook or outside the platform. Then, the second element that we have is the taxonomy. The taxonomy is the
[15:17] asset that we created to relate the KPI definition to its uh business concept. The business concept concept that Michele presented before.
[15:32] So, this is the most one of the most important part and if you ask how requesting a new KPI to add a new KPI for us is simple. This mean that we can add
[15:49] new row a new line within our file and define this KPI. The only time that when the KPI is not simple to add is when you need to add a new taxonomy entity. Taxonomy entity is
[16:05] something different. You have first to engage the product owner to define the new entity and this is a problem related to the semantic of the business, not a technical solution.
[16:22] Just to give the scale on how much KPI we are defined here, we have a base of 500 base KPI and 4,000 KPI
[16:38] when we break down for the dimensional breakdown. Okay? This is the first step. The second step is about the lakehouse KPI engine. Lakehouse is the best place to calculate
[16:53] this KPI because we started by creating the enterprise entities, which means that we unified the concept of store, sales, interaction, product, customer. So, we created a silver layer, okay?
[17:10] After the bronze, we don't have here the bronze, but not important. The silver layer is when is where we define the enterprise entities. This is very important. Because starting from the enterprise entities, we start to
[17:25] calculate these KPIs. Okay, calculate means that we created several job to calculate KPI when the instances of the enterprise entity updates within the platform. For example, if you
[17:42] if a new transaction come from the the data sources, then the calculation of some KPI starts and go up. Um All the KPI job
[17:59] are um uh works in parallel. Uh some of KPI are calculated in real time. For example, we have daily sales, daily transactions that are calculated in real time. Uh but most of them at the moment are
[18:15] calculated um um 12 time a day. That is a a refresh rate that is okay for our use cases. Okay? Perfect. So, after the calculation, KPI are stored within tables, tables that
[18:33] are KPI store that enable the channel to retrieve KPI to use the KPI. As a first step, we deliver these KPI as a batch mode using parquet,
[18:49] using CSV, and we also use the Lacos DB SQL. To for mainly for analytical use case. But we have a problem. The problem is that
[19:04] the business need also to have KPI as an online mode. Online mode means that we have several app that need the KPI immediately. Okay. So, we of course we try to deliver
[19:21] this KPI through the lakehouse DB sequel, but the time response time end-to-end response time was about 1 to 2 seconds. Okay. Well, it's okay.
[19:36] But it's not okay for this kind of deliver. So, uh there was a problem. Uh we we spoken with Databricks on how to resolve this problem and Lake Base was the our solution. Okay.
[19:54] A very interesting interesting solution because Lake Base enable us to have a single platform, not to add other tools that we need to maintain, that we need to set up, and
[20:10] the governance is within the same platform. This is the product group intelligent platform. Okay. And we also set ambitiously uh SLA for the distribution of this KPI of about 2,000 ms. So, the scale start
[20:28] from second and now are ms. So, it's a challenge, of course. So, we introduce another layer that is Lake Base serving layer. How we introduce this layer? We started to synchronize the KPI store within Lake
[20:47] Base using automated pipeline that are available with the solution. And we also activate the change data feed to do incremental update. Of course, we can't do full refresh every time because
[21:05] we trigger the calculation 12 12 times a week also near real time for some KPI. So, we we synchronize this layer in in this way. And
[21:21] over that, we create some function, okay, to link the business concept to the KPI calculated. This is a very important step. This is the step where we
[21:37] decouple the business concept to the underlying elements. Very important step. And uh this is the vision that we add with a product
[21:53] Michele speech, okay. Um And by using this function, we do the translation. And over that, we have a data API layer because
[22:08] the app, for example, the client like app within the store use APIs to communicate to leak base and to retrieve data in this way um in milliseconds, okay. Another thing important is that
[22:25] data taxonomy that we define is channel as agnostic. This mean that if the CDP, for example, and the app ask for the same KPI, then the call is the same, okay. We don't create
[22:41] an API ad hoc for CDP or for the app. It's the same because we define a framework, okay, a a taxonomy that we use to distribute this KPI, okay. By hiding in this way
[22:57] the tables, the schemas, the job, all the underlying complex complexity. Okay. Before go to the result of the
[23:13] the performance that we reached, I want to deep dive just one call, okay? One API call, the journey of an API call. So, we start Sorry. We start with a single call that is called
[23:30] get sales KPI. This is a function that enable the consumer to ask for, for example, the sales quantity for a single store that is the S2000, for a single time of
[23:45] period time, a single time sample, and some filter. Here we have only one filter for the transaction type. After the call, what we have? We have within the function a first step that validate the
[24:01] parameter. Some of them are mandatory, others are optional, okay? We have the step that associate the taxonomy to the correct KPI. We use to do that
[24:17] some mapping table, okay? So, the conceptual taxonomy that Miguel has presented, we have mapped the taxonomy within some mapping tables, okay? This is the mapping step. After
[24:33] that, what we do is to use this mapping to build a query, a normal query, okay? That retrieve the correct KPI, okay? So, the retrieval of this KPI return a data set. The data set is transformed
[24:50] to a JSON response that go to the uh, to the consumer. So, this is the way with this step, uh, to abstract uh, the call with the uh, SQL query and tables
[25:07] underlying. Okay. This is the architecture, okay? We have seen each step starting from the foundation. After that, we go we've gone to the Le Car uh,
[25:25] Le Car uh, um, KPI engine and the leak base serving layer. So, the result. Before exploring the result that I will show you, I want to say how we defined
[25:41] the 2,000 response time SLA. Because the scenario is this. Um, you have a client advisor within the store that need to serve a customer and need to have the KPI ready within its
[26:00] client dealing app. Because you have in front your customer and you can't wait 1 to seconds to load the KPI. You have to open the the app and you need to have the KPI already here.
[26:17] Ready, okay? So, it's very important this law for us. To test the result, we have done two family of test. The first one is a workload, a real workload, the expected one. We expect to
[26:35] query KPI within the client dealing the client dealing app for across 500 store that are stored store are in every time zone. So, uh, in this uh, scenario,
[26:52] we don't have concurrency because we tried uh, 100 requests per second, but we launched one every 10 ms. So, we we not test here the concurrency because we don't expect
[27:10] concurrency. The result are, in my opinion, awesome. Why? Because the median in this test is uh, uh, 15 ms response time end-to-end. That means so also the latency of the
[27:27] network. Okay? With a tight IQR and a P99. P99 means the the worst case of uh, a 90 ms. So, we are under this law. Perfect.
[27:43] But we have also done another test that is about stressing the um, calls. Stressing means that we ramped it up from two to 64 concurrent user. Concurrent user mean in the same time, same
[27:59] millisecond, we launch queries, we launch calls for the KPI. And first of all, we had zero errors for all scenarios up to 64. Wow.
[28:16] Okay. And then we um, we have we are under the SLA up to 33 um, uh, 32. Sorry. Concurrent user. Okay?
[28:35] There's only one case that is the case of 64 concurrent user that is over this three result. But it's not a problem for us. We know that, okay? We know that this scenario uh,
[28:50] is not real. We don't expect 64 concurrent user, but we have done all the test with the lowest cluster configuration. So, this means serverless win one to two
[29:06] compute unit. So, in this case, what we can do, okay, is to scale up and add compute or or do something like uh read replica, okay, to lower the
[29:23] end-to-end response time. In my opinion, these results are impressive, okay? So, we started from by using Lakehouse DB SQL from 1 to 2 second, and now we are here. This means
[29:40] that with Databricks, the response time is uh about 100 times faster. Okay. Wow. Okay. Michele.
[29:57] You can close. So, zooming out, ah Zooming out, now we are ready to go to sale. How many of you knows Luna Rossa? No, I'm kidding.
[30:12] I'm kidding. So, we have some lessons learned. We tried a lot of solution. This solution that we presented today was not the first one. We tried as Andrea said,
[30:27] normal SQL serverless Lakehouse, then we moved to metrics, then we moved to online tables. We remember this. tables, we tried This is history that yeah. For a a period of time, then they deprecated, so
[30:42] we we escaped from from that. This solution seems very promising. Also, with respect it we listened this this day this morning from the technical
[31:00] development of the new features of the platform. And the on the other side, this approach based on semantics also for us is very promising based on taxonomy that's lowly becomes full semantic layer. And in the
[31:16] end, let to see something like ontology, okay? And we listened this morning that this this there is this concept of Genie ontology which is coming, which is perfect for this approach, I we guess.
[31:32] We also learned that initial solutions provided by DataBricks itself was not enough for us, for instance, metrics view. For a series of reason, metrics view
[31:47] were were not reusable, were not specifiable with parameters, so we initially tried, but we passed away in a short period of time.
[32:03] So, the final statement is that Lake Base is nice. It has all the right capabilities in place for providing low latency restful serving model at scale. Another important thing when you work
[32:20] with Lake House SQL warehouses often you need to build on top web app which is a separate layer, okay? Lake Base, very important, provide a native restful serving model which is
[32:37] Postgrest, which is very nice for us. Uh we need to fix something from the authentication point of view, the one knows, but but uh but it's very promising and very very good for us. So, next, uh
[32:53] we are very interested in this concept of ontology in general, okay? We want to build our ontology not based on uh local cases, not local use case, but we have this idea on of building an enterprise level ontology. So, to
[33:09] provide that general context, which is shared across brands, across departments inside the the the the the the global enterprise. So, to define which a sale is, which a customer is, which a product is, without any doubts, okay? And this
[33:27] is a challenge for the future, not only from the the point of view of the software implementation, but also from the point of view the perspective of the organizational, okay? And the the challenge here is starting from retail concept. So, what is true
[33:42] inside your organization, not in in the mind of an a design data architect, but in the real concept, which are practices and operating model of the of the enterprise, which is not obvious. And this maybe is what in the end will
[34:00] enable this agentic layer on top, okay? And uh this morning was uh clear about this idea, also. Uh so, this is our remark for today. I want to pass to final question and
[34:16] answer, not before having thanked all the team, Anna, which is our head uh of analytics, and the teams in Italy, I Consulting and uh data the data engineers, stone cutters, as we call them in Italy, that
[34:31] uh helped us to build this. So, thank you. And also Dima that helped us Yeah, Dima from Ericsson. Thank you, Dima. Thank you.

Learn more about the Databricks Data and AI platform.

The information provided herein is for general informational purposes only and may not reflect the most current product capabilities or configurations.