theCUBE + NYSE Wired: Physical AI & Robotics Leaders | NexGen Data: Navigating Modern Database Frontiers

Clips
More from theCUBE + NYSE Wired: Physical AI & Robotics Leaders

Nikita Shamgunov

CEO

Neon

Tanya Bragin

VP Product

ClickHouse

Philip Rathle

CTO

Neo4j

play_circle_outline Unlocking Business Value: The Interplay of Data Lakes, OLTP, and Application Development in the AI Era

play_circle_outline Importance of databases in applications, with a focus on Postgres and ClickHouse.

play_circle_outline The evolution towards unified architectures for data lakes to support analytics and observability.

play_circle_outline Observability and its growing importance within AI and analytics frameworks.

play_circle_outline Leveraging Knowledge Graphs and Graph Databases for Enhanced AI Applications and Enterprise Decision-Making

play_circle_outline Separation of storage and compute essential for modern database architecture and scalability.

play_circle_outline Need for a governance layer to manage data curation and compliance effectively.

Info
Transcript

NexGen Data: Navigating Modern Database Frontiers

Nikita Shamgunov

CEO Neon

Tanya Bragin

VP Product ClickHouse

Philip Rathle

CTO Neo4j

Nikita Shamgunov, chief executive officer at Neon Inc.; Tanya Bragin, vice president of product at ClickHouse Inc.; and Philip Rathle, chief technology officer at Neo4j Inc., join theCUBE’s John Furrier and Dave Vellante at theCUBE + NYSE Wired: Robotics & AI Infrastructure Leaders 2025 event. The group delves into the evolution of data infrastructure, highlighting how modern databases are enabling real-time AI and analytics.

The discussion explores OLTP-OLAP convergence, the rise of open data lakes and the strategic shift toward serverless architect... Read more

explore Keep Exploring

What are the three separate worlds identified in the context of data, analytics, OLTP, and application development, and how are they interconnected? add

What is ClickHouse and how is it being used in relation to data analytics and application development? add

What trends are being observed in the integration of data lakes, data warehousing, and observability tools? add

What is the purpose and use case of ClickHouse as a data warehousing solution? add

What is the role of knowledge graphs in enhancing AI innovation projects within enterprises? add

What is the significance of the separation of storage and compute in data management, and what technologies currently support this separation? add

What is the current shift in control dynamics regarding data governance and how does it impact various companies and their competitive positions? add

bolt Powered by CUBE AI

NexGen Data: Navigating Modern Database Frontiers

search

>> Welcome back everyone to theCUBE Studios here in Palo Alto. I'm John Furrier your host with Dave Vellante co-host. Been covering big data for 15 years, and now all the action in robotics and AI leaders at the infrastructure all talking data because the wave of data value is being unlocked for agents and a lot more. Of course, we've got the experts here, Nikita CEO of Neon, recently sold to Databricks. Thanks for coming on theCube. Appreciate it.

Nikita Shamgunov

>> Nice to be here.

>> Congratulations. Tanya, the VP of marketing at ClickHouse, of product as well. Thanks for coming on. Appreciate it.

Tanya Bragin

>> Thank you.

>> And Philip, CTO of Neo4j Graph Database. Again, congratulations on your success. Thanks for coming on. So guys, the data world's hot right now. You got to say you haven't seen this much action. OLTP is being talked about outside of the normal verticals, data lakes turning into a real enablement to unlock value of data, and then the graph databases with neural networks starting to see the databases become just data and the world's changing. I first want to ask you guys, Nikita, we'll start with you, the game is infrastructure at the data layer, but yet there's business value happening, so there's a lot of things happening technically, structurally. What was your observation in this space right now, obviously now that you're at Databricks? Congratulations.

Nikita Shamgunov

>> Yeah. There are several actually. My observation is that there are three separate worlds. One is the lakes for data and analytics. The other one is OLTP, and we tend to think about OLTP as databases powering financial transactions like those big systems, and then the world of applications. I think what we're seeing in all of them are connecting, and they're connecting to drive businesses and enable AI. Every application still needs a database. Data has been hot forever, right?

>> Exactly.

Nikita Shamgunov

>> What we observed that it's so much cheaper now to build in applications with platforms like Replit, Lovable, and Bolt, and then now we have a high velocity application development that is nothing that we've seen before. We've always been getting better and better in building apps, but today it's now getting trivial. Now you can build an app in 15 minutes. That drives velocity. Now, as those applications are getting more sophisticated, now we need that connectivity with the application and application platform with a way to build the application with vibe coding and then leveraging AI, and then the data thing propagates through this. You need a OLTP database to power the application, and then you need to have all the telemetry, observability, and fundamentally data to complete that cycle. I think we see an acceleration in the unification of all those three.

>> Yeah. The silos are getting busted down, but yet database still exists, so they're never going away.

Nikita Shamgunov

>> Correct.

>> Now you have that horizontal scale of the network scale-out, but you got the scale-up piece too with the domain expertise. Databases are everywhere and applications are everywhere. What's the connective tissue for all this? The data lake? Is there a glue layer? How do you guys see that? Tanya, you're shaking your head, you jump right in.

Tanya Bragin

>> Yeah, absolutely. First of all, I work at ClickHouse, as you mentioned, I'm head of product and marketing. Clickhouse is an open source analytical database that started off more in the application builders world. If you need to build an application that not only has transactional characteristics but also analytical, you would take a database like ClickHouse and use it for your larger analytical data set. What we're seeing is first of all, these data-driven analytical applications are becoming much, much more common, and a combination of a transactional database like Postgres and ClickHouse is evolving to be a default data stack on the application builder side. You mentioned data lakes. What's interesting to me is that what we're also seeing is an evolution of a single unified architecture for a data lake, not only for data warehousing and traditional BI, but also for observability. Traditionally, these stacks have been very separate, and why? Because historically it's been two very different vertically integrated commercial tools, say Splunk for logging on observability side, and I don't know, Oracle on the BI side. Now, if you look at players in this space, both open source and commercial, everything is on top of object store, everything is evolving to open data lakes absolutely as kind of a unifying layer. Now the question becomes, well, what query engine do you need to drive your application? I think it's becoming the case that the stack is much, much more unified than it ever used to be, which is opening up a lot .

>> Yeah, If an Oracle, the one database to rule the world as was said, now you have every application needs a database, that's fact.

Tanya Bragin

>> Yeah.

>> That's pretty objective, it doesn't go away. Now you have data at runtime, generative process creates real-time low latency, so the old convergence of infrastructure, storage, compute and networking, we used to call it the holy trinity of infrastructure, now you add database to that, that's infrastructure. This isn't just bolt on a database, query it, get an answer for the app. You got to have that very high velocity, real-time contextually relevant database.

Dave Vellante

>> Oracle's probably the one company who can get away with one database to rule the world, even though they have things like MySQL HeatWave. Even they don't have one database to rule the world, but the RedStack allows them to do that. Everybody else who's moving toward open table formats and which engine's the best engine for the right tool for the right job, that is by far where the market momentum is, and we've seen, Philip, graph databases before the AI wave, they were used in security use cases, and now it's just the wind is at your back as you start to bring in transactions, as you're bringing the OLAP and the transactions together, and this vision of, we like to call it people, places, and things, and processes coming together to create a digital representation of a business in real time, and you really can't do that without a graph database.

Philip Rathle

>> Yeah. One way I look at the database market is what's the shape of the data? A lot of the real world's data, both real world and digital, shows up as networks, networks of people, networks of computers, networks of communication, payments, ecology, biology and so on, as hierarchies, hierarchies of supply chain and bill of materials, parts and parts and parts, asset ownership, HR, et cetera, or paths like customer journey, patient journey. Those three kinds of ways in which data shows up, which is most of the world's real and digital data, is best represented as a graph it turns out. Having a database management system that's designed ground up for graphs, it supports transactions and analytics ends up, back to your glue question, John, of what's the glue, Satya was on stage at Build just a few weeks ago saying that every AI application needs not only LMs, not only vectors, but access to the real-time web and an enterprise knowledge graph that's built with the database that's designed ground up effectively for graphs. Probably the biggest illustration I have for this is Klarna who are known for those of us in enterprise AI circles, I'd say they're probably the shining example of an early significant success inside of not just consumer but enterprise. The story behind this application that they built homegrown, that provides intelligence for their employees and allowed them to unplug 1,200 SaaS apps from Salesforce to Workday and so on, is by repatriating data from all the different silos into a connective tissue. This is different from taking every single bit of data and landing it into say a data lake, it's taking the important data, connecting it up, and then serving up AI so that the scope of any AI decision can take into account all the data inside of the company, not just what's available to a single department.

Dave Vellante

>> To Tanya's point, the stack is coming together and there's more clarity at the same time. Does the stack have to mash transactions and analytics together? Is that the vision, or will they stay separate?

Philip Rathle

>> I have a point of view on that, but I just .

Dave Vellante

>> That's something that we're trying to figure out because we want the transaction so that you can actually take action and push to the system of record, but then it brings up some interesting dynamics.

>> Nikita, what's your take on this? Start with you.

Nikita Shamgunov

>> I can take this one.

>> All three of you, go ahead.

Nikita Shamgunov

>> My previous company SingleStore, we actually ran that experiment. We were able to build a system that technically allows you to run transactions and analytics on the same platform with the same API. What we've discovered and was one of big learnings for me when I started Neon, that the bar for creating a great transactional system is very, very high, and it exists not only in the technology itself, it also exists in the user. The user is an application developer, and in that world the user just chooses Postgres these days. If you take any trend lines about where the transactional databases are going, that one technology, Postgres, is becoming kind of the Linux of databases. I think for the next iteration until we have another paradigm shift, we will see Postgres plus something that's built on top of an object store. I have very similar conviction to that what that Tanya has. The analytical engine on top of an object store will likely converge over some sort of open format, call it iceberg, call it delta, maybe those two formats will converge as well, so now we have a choice of an engine, and then we'll have a very, very tight integration. Neon is already built on top of an object store by the way, but we'll have a very, very seamless integration around the open formats as well, so we might see open formats coming in in the transactional space, and those open formats will reside in the data lake accessed by additional engines, and that will complete that cycle.

Dave Vellante

>> And then the other piece here, and I'd love your perspective on this, is to the side of the architectural diagram you have this conversational interface, and you have things like the Unity metrics that we heard about last week or the week before that it's inferring business context, and it can ingest and deposit metrics and dimensions. That brings up a really interesting, as I say, this four-dimensional graph where you're taking action ultimately on behalf of the system, and then you've got the two ends of the spectrum, Satya, agents talking to CRUD databases, Benioff, well that's just clippy, and there's probably some truth to both of those, but I wonder if you have a perspective on that.

Philip Rathle

>> Sure, yeah. I guess let me frame it in terms of the analytics and transactions. Question is you ultimately, if you're serving applications, you need to be able to be the source of truth for certain data, at the minimum whatever data that application's controlling in both those scenarios, and in order to do that you need transactional integrity, which is the T in OLTP. We've always felt, agree with Nikita, building a transactional system is so, so, so, so hard. I've been in the database space for 30 years, and all the things we take for granted reside on this giant multi-layer architecture. You can start with transactions and add analytics to it. I don't believe the reverse is possible .

Dave Vellante

>> Well, look at the UniStore challenge that we saw. They announced that in 2022 and ended up having to buy another transaction database. To me, it's a sign of a failed initiative because it's so hard.

Philip Rathle

>> Yeah. We were contrarian at the time NoSQL was coming out and said, "You've got to support transactions. Let's do that first." The vision is, and I think database of the future, you should ideally as a user not have to be bothered with, "Is this a transactional query? Is this an analytic query? I'm going to have to go to two different systems." Ideally you want to be able to do both, and then by doing both in one system, you have the freshest data so that you can provide analytic capability on top of literally up to the last transaction. Then coming back to the shape of the data, you need different kinds of databases to support data of different shapes. This is part of the thinking behind ISO for the first time in close to 40 years in creating and approving ratifying a language second to SQL. Now you have the GQL standard, which is that you have SQL and GQL are in a sense siblings, GQL being the graph query language to support graphs. What that allows you to do is take data that's shaped like this real world data as I was describing, give you schema flexibility to be able to evolve applications for fast-moving applications where I don't know what data I'm going to use from one day to the next for AI, but at the same time have relational databases, particularly on the analytics side, to be able to take your stream of transaction data and do basic analytics.

Dave Vellante

>> To your point, you get the expressiveness of a knowledge graph with the query flexibility of SQL, which was always kind of missing.

Philip Rathle

>> That's right. With its own language. I'd add LLMs actually solve the language problem to the degree that English or your human language of choice becomes the key API for developers. It becomes less important to know SQL, to know GQL, though of course having a standard is helpful because the models need to be trained in these languages.

Dave Vellante

>> You've got the metrics and dimensions, and that's the single source of truth and it's governed. In ClickHouse in that scenario, is it observability platform?

Tanya Bragin

>> A couple of use cases. Originally, the name ClickHouse is clickstream data warehouse. It was built as a backend, a data store actually that you would put in your SaaS service to build a web analytics platform, similar to actually what I just saw backstage. We saw an application. The original use case was actually an embedded use case like a Postgres but for analytics. This is petabyte scale use cases where you need a specialized columnar store as opposed to row-oriented store, but still as a developer you're building an application on top of it. Increasingly what we see is more use cases that are internally facing. Just because I am using this for customer-facing applications doesn't mean I couldn't do the same internally. There are data warehousing use cases where you really need an interactive data-driven experience for the same internal users. Observability isn't a use case, and actually we just had our user conference where we had Anthropic, OpenAI, Tesla talk about their large-scale observability use cases where honestly no off-the-shelf solution is going to fit their needs and they need to build their own stacks. ClickHouse can also be used there. Yeah.

>> If the object store becomes the new place, Iceberg open tables, great innovation there, the token demands on the reasoning side is accelerating. It's putting a lot of pressure on large-scale systems, so we're seeing that happening. You got open table formats driving the app's needs for reasoning and tokens. What is the unifying layer here? Forget the catalog for a second for Databricks because they're called Unity, but what is the strategy architecturally for enterprises or companies who want to make databases, plural, the infrastructure? Is it roll your own, nail the storage first? The benefit is open table formats, you don't care where they're stored, you can just manage it. That's one of the things I like about Unity. What is the query engine strategy architecturally?

Tanya Bragin

>> Exactly. I think first of all, when we say databases, increasingly it's storage and I think it is open storage and then query engines. What is a database? In the past they used to be combined storage and query capabilities. Now I do think it's separated and it's exciting to see the same happening in the transactional space. It's already been the reality in the analytical space. This is where I think it becomes interesting. Query engines now have to compete for be the best at what, and I do think they're going to specialize more in order to compete. We specialize in real-time analytics. Our goal is to be the best query engine on top of open and proprietary formats for real-time analytics, and we're going to specialize in that. It's definitely going to be something that we will excel at because we've already done that on top of our format.

>> Nikita, you were kind of hinting at this, but we had a panel yesterday in storage folks, you're starting to see the storage TRB SSDs, and with compute and storage separated, you now have the ability to start thinking about the architecture of how to make the compute layer. That's where the constraint is, compute. A lot of people are trying to squint through the architecture. What's the best deployments? Is there a general principle or use case or pattern you guys see emerging? What do people do? What are people struggling with right now, and where's the sequence of events that gets you to the baseline of actually having AI?

Nikita Shamgunov

>> Well, I think on the consumption side, what we see both at Neon and now I walked into the Databricks I see the same thing, is, well you want serverless, serverless, scalable, and then within that you have all sorts of SLAs. SLAs could be SLAs on cost, this is my cost expectations for dealing with the big data, these are my latency SLAs. If you click in there and then understand what's the architecture that is able to deliver on that, it goes straight into storage. Depending on the level of-

>> Back to storage, Dave.

Nikita Shamgunov

>> Back to storage.

>> storage, bare metal storage.

Nikita Shamgunov

>> Depending on the latency that you need to deliver, in an LLTP world latency expectations are a single millisecond, you got to deal with SSDs, but it doesn't mean that you completely walk away from the object store. You have the object store tier, on top of that you have a low latency tier, which is either a system of record tier that you need for operational database that's built on top of NVMe, that is Neon architecture. Then you have all sorts of caching tiers in addition to that that could be SSD NVMe based or even high tier in memory. You have this whole pyramid of object store, fast object store such as the express tier, which by the way, great innovation from AWS, does not exist in all the clouds, then you have your own, roll your own on SSDs and in memory caching. At the end of the day, the way you deliver it to the end user is it's a serverless system that all the use cases of LLTP, OLAP, observability graph, they're all tightly integrated because they are at the end of the day speaking to the same underlying object store.

>> Do you get into conversations when you guys talk to customers around energy-bounded requirements, or is that not yet hit? The storage folks are dealing with that right now.

Philip Rathle

>> It has a bit. I want to add my take to your question around what's the unifying fabric, because that has knowledge graphs all over it. Even fabric, it ties things together, it's about connections, it's about relationships. What we're increasingly seeing, and as I mentioned, Satya mentioned that you need an enterprise knowledge graph in every enterprise use case or most. We're seeing Gartner just released two pieces actually, one of them saying that you get 80% increased likelihood that a AI innovation project will get to production if there's a knowledge graph present. There's the Klarna example and many others, large retailers bank that we're seeing doing this. The unifying theme here is you've got data spread across different systems and different silos, and you ultimately want the scope. If I'm a CDO, CIO, CTO, CEO, I want the scope of an AI decision to use all the intelligence that I have in the company, which means I need to take the company's knowledge and tie it together and make it available to AI agents. If you don't do that, then you're going to end up with AI that's scoped to particular applications. The advantage with graph ends up being twofold, threefold. One is you can easily add new kinds of data sets pretty easily without having to decide in advance what's my table structure, and then moreover, the data shows up the way it shows up in the real world. You use the term impedance mismatch as database geeks, that that's the distance between the business view or the developer view of a data model and the DBA view of the data model. Big distance there that's narrowed with graphs.

>> Philip, I'm hearing more words, graphs of graphs are happening.

Philip Rathle

>> Yeah.

>> That's a sign of innovation.

Philip Rathle

>> Yeah. Inside of applications, an HR application will have the HR hierarchy which is a form of graph. Inside of supply chain manufacturing, you might have build materials supply chain, but then you combine those, which employees are working in the factory on which component, that becomes your graphs of graphs. These things combine really nicely. There's a term, data network effects that everybody's heard, but with graphs you also get use case network effects, that the more data you add, the more you solve different problems incidentally, and you can essentially build off all this off of an enterprise .

Dave Vellante

>> Database world seems to be moving from strings that databases understand to the real world things. We're talking about robotics infrastructure in the digital world and the physical world coming together. Ali at Databricks, he's always making interesting comments, and he said the databases haven't changed in 30, 40 years. I would go back to my Berkeley and the IBMR paper that 90% of it is the same. What does the future architecture look like?

Nikita Shamgunov

>> Well, I think the separation of storage and compute is going to stay. We separated storage and compute for analytics call it 10, 15 years ago, and then that's been driving a lot of consumption both for ClickHouse, Snowflake, Databricks. In analytics we separate storage and compute, it's done. In OLTP, it's not the case yet. I think there are three technologies on the market in the western world that separate storage and compute, AWS Aurora, Neon and AlloyDB from Google. Now, only Neon sits on top of an S3 object store, so that opens up that possibility to create open formats, integrate with the lake tightly. I think separation of storage and compute is the foundation in which everything will stand, and once you have it, not only you can deliver serverless, not only Ali was talking about branching and how you can enable developers and agents by creating branches of data and giving them sandbox environments, but also it's the foundation of a very tight integration and break in silos because the object story is that unifying fabric underneath.

Dave Vellante

>> Well, part of that silo busting too, as Tanya was saying, is you can now bring any ... We're not only separating compute from storage, we're separating any compute from any data, and may the best engine win.

Tanya Bragin

>> It's really powerful. Exactly right. Yeah. I think also where this really helps when you think about agents now being primary systems that are making queries to let's say compute engines, increasing. This is definitely the case already in business analytics, I think it's going to be the case in observability. In my previous life I was building observability solutions, and one of the hardest problems is actually root cause analysis. I actually think agentic workloads are going to be a really good way to build future root cause analysis. For that, you need that perfect world where data on storage is separated from compute, where you have access to that from different types of compute layers. I think that that's going to drive a lot of that perfect architecture. To your earlier question, what's the hardest part right now for organizations, it's actually inertia. It's not free to get your data into this perfect format, you do have to go find it, you have to re-index it, it's not free, it's definitely a lot of .

>> You got to clean it.

Tanya Bragin

>> Exactly. All of that is not free, but I do think organizations have to do it, otherwise they're going to stay behind.

Philip Rathle

>> There's separation of data and compute. I want to drill in. There's also the format that you store the data in. Relational databases, back to Ali's comment, I agree relational databases haven't changed much in 40 years. Of course, if you look at the last 10, 15 years with NoSQL emergence of new models, I actually disagree that there's been no innovation in the database space. There's been hundreds of database vendors out there, each with a different angle. What hasn't changed or where there's been some evolution on the relational front is how you store your data. For example, columnar storage is a great way to leverage contemporary technology on the hardware side to be able to anticipate query patterns and be able to use modern hardware, both compute and the storage to be able to scoop up lots of data and low latency come up with analytic answers. With graph we also do this, but we take advantage of the fact that modern compute is actually very good at randomly hopping through memory or flash because for real world questions and real world data, you can't really anticipate how things are connected, so you can't pre-store in advance the query answers for each query that you could possibly ask. What we do instead is we play this trick where instead of in any other database technology where you compute at query time how data is connected, we take a little bit of an extra hit at the time the data is stored and we store the connections physically so that then when you run your query, you can do average two million pointer chasing operations per compute core per second, which is like doing two million joints per core per second. The environmental impact, to your earlier question which I didn't answer, we've seen cases where the largest Oracle cluster in an entire company is replaced by a modest Neo4j server and queries run a thousand times faster. It's significantly more environmentally efficient. You also need fewer tokens in an AI context with a knowledge graph while getting low latency and .

>> I would say the energy-bounded constraint is motivating everybody in the stack, so it's been great. I'm really grateful you guys came on today. I wish we had more time.

Dave Vellante

>> One more question, maybe not real quick, but it's the fundamental question that we're trying to understand, is we're observing that the point of control is shifting from the database up to the governance catalog, and we're very clearly seeing that. The value actually because it's open source is going even further up the stack. As companies like Databricks, and of course you see Snowflake struggling with Horizon and Polaris, how much function to trickle, but as you continue up there into transactions, now you're into the domain of Salesforce, and ServiceNow, and Oracle, and SAP, Solonis trying to be the Switzerland of all this, if you're familiar with Solonis. It's a really interesting dynamic. Whomever controls that harmonization layer, that 4D graph, is going to be serving those metrics and dimensions, and the people, places, things over time and the processes, which of course the SaaS guys are going to hold on to, so that's an interesting competitive dynamic. I wonder if you guys have .

Nikita Shamgunov

>> Yeah. I was about to bring this up actually answering the question of what unifies things at the infrastructure level, and that's the object store. What unifies things at the consumption level is the catalog. Certainly from the Databricks point of view, you need a catalog, but there could be other catalogs as well. The important thing is that you can bust data silos, again, in the infrastructure level by enabling multiple engine query the same data, but also at the governance level. Every time you bring a separate database system, data system that is not integrated well into the catalog, now you're in the world of a little bit by moving data around and then enforcing unifying governance rules and ACLs onto the data. Now you have a problem in your hands. That creates actually serious advantage to those large platforms that own the catalog, that own some class of data. You can own transactional data, you can own operational data, you can own iceberg data, you can own observability data, but if you do and then the user cares, then you're in a position to enforce governance around it. Now it becomes a center of gravity that all the incremental amount of data that comes in needs to be subservient to the catalog that's there, and it provides tremendous value to the user because data leakage, data security-

>> Lineage.

Nikita Shamgunov

>> Those are all very, very important things in the enterprise that making it hard to bring system into the fold.

Tanya Bragin

>> Yeah, we agree. We integrate with the Unity catalog. We're just thinking of the Databricks conference or integration. I think it's really exciting that there's an ecosystem evolving around this. Again, it plays into the specialization story. There are going to be specialized use cases where you need to not only elevate the data but the compute as well, but then there needs to be one unifying place where you can enforce your governance, permissions, so I think that's exactly right.

Philip Rathle

>> On the operational side, I've seen two patterns play out throughout my career. It's either federate everything or bring everything, let's replace all the systems with one system. Neither of those works, and what you end up needing is just enough persistence that ties things together so that then you can go and dip down into whatever the system of record is for a particular thing. To be able to elevate just enough from each different system, that you can do customer 360, start with one identity, go up, combine them. Graph ends up being in an ideal way to combine those, and this is part of this enterprise knowledge graph for Gen AI idea. Lineage is also a catalog, metadata tends to be represented as a graph. We have a public case study with EA who use Neo4j actually in addition to further data also for the metadata to keep track of all their different data.

Dave Vellante

>> Addressing the challenges of federation and the walled garden problem.

Philip Rathle

>> Right.

>> All right. Well, Philip, Tanya, and Nikita, thank you for coming. I'm grateful for your time. You guys are leaders in the space. Thanks for sharing.

Philip Rathle

>> Thanks for having us. Appreciate it.

Tanya Bragin

>> Thank you.

>> I'm John Furrier, Dave Vellante, here for theCUBE's Robotics and AI Leaders Program. Thanks for watching. All right, cool. You can do the next one.

Dave Vellante

>> Great conversation.

>> only one host.

Dave Vellante

>> Okay.