Hi everyone. My name is P Juan from Ocean Based Global. In the next 15 minutes, I will show you how platform teams can run rack semantic search analytics along a single database platform, S code plus vector running on Kubernetes. The goal is simple, fewer moving parts, lower latency, and easier governance. For both structured and unstructured data, all with multi-tenants and strong consistency. Here is today's journey. First, I will share why AI will close the challenge platform teams, things like fragmented texts, high latency, and the governance issues. Then we will move from real world challenges to. To one platform solution. Looking at how a unified approach can simplify operations. Next, I'll introduce Ocean based as a unified database for modern AI apps showing how SQL and vector workloads ran together on Kubernetes. Finally, we'll ramp up with some closing source and cater with that you can bring back to your team. According to IDC, over 92% of global data is now in an unstructured format. This exactly is this data drives AI workloads like React and semantic search executives and IT leaders are also recognizing this shift. 41% say rack as essential, and over 80% believe that gene AI models using their own enterprise data will be K competitive edge. And this isn't just theory. Clo recent research shows enterprises are moving fast. Two thirds are already using enterprise AI infrastructure platforms, and the 60% are embedding agent AI directly into their core applications. So AI workloads are no longer experimental. They're becoming mainstream enterprise critical workloads and that creates new challenges for platform and the database team. Which we will dive into next. Now, if AI workloads are becoming mainstream, the next question is, what does this mean for our technology stack? The real, the reality is different. Different workloads requires very different capability for intelligent question and answer, charitables. They need low latency access, thematic search and context awareness for log analytics. Normally detection, it needs high ingestion, right? Ax search and metric aggregation for the core business systems, it's comparing, it needs strong consistency is a ID and S. And because of this, organizations end up teaching together multiple specialized databases a transactional database, a data warehouse, a vector database, sometimes in a graph or NoSQL engine. The result, the stack is getting complicated, more system to upgrade more ETL pipelines. Higher cost and more risk when workloads span across them. From my conversation with many platform engineers and from our own experiences, this is what most teams, which they had one platform for all data workloads and a strong consistency and a high availability. Seamless integration with AI pipelines, elastic scaling on Kubernetes and UN unified access and multi-tenants with resource isolation. But here is the reality is they face every day just like fragment. Augmented the data system trade off between performance and consistency. Complex data movement between services, difficult scaling across data flow workloads, inconsistent query models and APIs, talent interference and noise. Neighbors. Let me make this more concrete with with the user case that many enterprises are building today. AI powered Knowledge retrieval for internal Teams. This is a conventional architecture you will note, you will notice it looks quite complicated. There is a transactional database for metadata. And a vector to store. A vector store for embedding maybe a, maybe an elastic search cluster for full text search. And all of this need to be synchronized with ETL drops. Now, what does this mean in practice, you'll end up maintaining multiple databases, synchronizing, synchronization, introduce. Latency and inconsistency. Each additional component adds to the cost and operational risk. And if one part goes down, the whole pipeline can break. This is exactly the kind of fragmented stack we described earlier, how to operate costly to scale and fragile in production. Now here is how the team approaches the problem. Instead of stitching together multiple specialized systems, they build on ocean-based as a unified database platform. This allowed them to reimburse structure and vector search in the same engine, deploy elastically in on Kubernetes and removes the heavy integration burden. And as the results speak for themselves, correl latency dropped by over 70%. That is, that used to take offers to refresh is now available in minutes as the amount of integration code to maintain has been reduced by over 40%. So by moving to a unified data platform engineers gen, both similarity, simplicity, and the performance, something that was very hard to achieve in a conventional multi database data set up. Let's look at a topical conventional architecture for AI powered. Knowledge retrieval. When a user when a user issu issues a query, the system needs to interact with multiple backend systems. First, it queries MySQL four structured data. Then it queries the vector database for and embed, so IES is involved for catching. In total a single request incur at least the four. Network run trips and the end to end latency extend 170 milliseconds. On top of that, the platform must maintain data consistency across all their systems, which adds additional complexity and overhead. This is exactly where Commissional architecture, Chicago multiple systems. High latency and complex integration. In the next slide, we will say how we use Ocean Base simplifies their stack and just, and reduce latency with Ocean Base. A user query no longer needs to touch multiple backend systems. Instead, the query is handled within a single platform. Combining both structured and unstructured data. As a result, the entire request only involves one query, not multiple round trips, end to end latency drops to just the 50 millisecond. Data consistency is strongly maintained across the system at all times. This, it treats how consolidate consolidating your data and the search capability into a single SQL compatible platform can dramatically reduce latency and simplify operations. Here is the practical example of what we mean by hybrid queries. Imagine a user asking. Recommended distance within five 500 meters. Average consumption below five doors, rating about 4.4 0.5. No queries for no queues for the coffee shop. Now this requires, this request involves multiple data types, GIS data for location and distance. Relational data for price and rating web, the search for thematic relevance. In most systems, you would need to stage together different engines to handle this. This means multiple queries, complex integration and added latency. But with Ocean Base, this entire request can be answered within with just one SQL state. That's the power housing of having structured special and vector data all unified in a single database. It makes life much simpler for developers and enables faster, smarter application for users. Let's, let me quickly walk you through the ocean based architecture. First data is distributed across multiple availability zone, which means we can scaler horizontally as workloads grow. Onis. Ocean base is fully containerized supports operator based mag management and aurora's elastic scaling for both computer and storage. This, mix it very cloud native and easy to operate at scale. Second, let's talk about availability and consistency. Ocean base is built on the axus consensus algorithm with the trip with the triple replica mechanism across availability zones. So even a note or zone fails. We also have automatic failover. And the system always guarantees strong consistency. In short, the architecture is designed for elastic elasticity and resilience and the trust trust thinners, which are critical for AI vehicles in production. Another important reason for choosing ocean base is multi tennis compat compatibility. This means that different workloads can run on the same ocean-based clusters while being isolated into separated tenants. Each talent has its own dedicated resources, so this is so there is no interference across workloads. With this, you truly get one platform for all data workloads. The STEM engine supports O-L-O-T-P transactions, log analysis, semantics retrieval, and even AI applications without needing multiple databases. And with the unified unified access layer, developers can use a single SQL engine to query both structured data and unstructured data, including full text search and vector search. This makes the developer and its parents much simpler and it helps platform teams consolidate their database tech. As we ramp up, I'd like to leave you with the fail case. Takeaways. First one, platform. All workloads be for the next decade. Dedicate. With Ocean Base, you can significantly reduce the number of systems in your stack and cut down the integration complexity that platform engineers often struggle with. Second, the same platforms just supports both structured and unstructured data. That means OLTP analytics. Photo has search and even vector search for AI workloads all in one place. Third, ocean-based offers elastic scaling and runs natively on es, so it fits naturally in naturally into modern coordinative environments. And finally, with the fuel systems to integrate and maintain. Platform engineers can focus more on delivering value to the business instead of spending time staging system together. That's the vision we are driving with Ocean Base, a single unified database platform for the next generation of applications. One platform, all workloads, less complexity, more innovation. That's the ocean-based promise. Thank you. Thank you for your time. Okay.