About this talk
This talk discusses AI native databases and presents three key innovations that enhance their functionality. The speaker, Wei Hu, emphasizes the need for databases to effectively support AI agents, ensuring data accessibility while maintaining security and scalability. He introduces the concept of converged architecture, which integrates various data types and workloads into a unified platform, simplifying data management. Additionally, he explains JSON relational duality, allowing data to be accessed in both relational and JSON formats without compromising on consistency. The session also highlights the importance of enforcing security directly within the database to prevent AI agents from bypassing application-layer controls. Using the Oracle AI database as a primary example, the speaker shares actionable principles for effective AI integration within database systems.
Full transcript
Oh, okay. This works. Hi, can you hear me? Yes, you can. Okay. Uh all right. Actually, this sounds very weird because I can't hear myself. >> [laughter] >> So, um to start with, uh my name is Wei Hu. Okay, that's how you pronounce my name. Um I I'm a senior vice president of Oracle database development. Okay. normally I speak very fast, right? However, I just flew in
yesterday from the United States, so I'm actually very sleepy. So, hopefully that will slow me down enough so that I can talk at a normal speed for you. Okay. So, today um I'm actually going to talk about AI native databases, three innovations. Because originally I was going to talk about four innovations, but I decided to compress them into three, so it's easier to conceptualize them. Okay. To
start with, yeah, I think we all know that AI changes everything. Right? And in terms of databases, there are several factors, right? First of all, you know, just AI will AI agents will will need intelligence at the data management layer. Databases need to be able to feed AI agents. In terms of data, you have to make sure that all the data stored in databases are can be
accessed by AI, right? And it has to be done safely, because when AI accesses your data, you don't want them to disclose personal information and so forth, right? Um and of course, the workload generated by AI agents is very, very high. And so, your infrastructure has to be able to support that and scale and so forth. And very importantly, you have to be able to trust the
AI to do the right things, right? Because if you can't trust the AI, you can't allow it access to your data. Trusting the AI mean meaning that it can only access data that it should access. It should not disclose data it should not disclose. And it should be proof against hackers Now, the title is Oracle AI database, right? So, what is an AI database, right? So, this
is the architecture of the AI database, right? So, what happened was when ChatGPT happened, everything changed, right? And then we went through and analyzed what databases should be, and we did a lot of things. Okay. So, this shows you things like, vector support, right? Modeling support, AI hubs, you know, development tools, knowledge engineering, knowledge graphs, semantic views, all these things that didn't exist before ChatGPT, or in
different forms that we had to redo in the world of new large language models. Okay. So, this is what a what a modern AI database looks like under the hood, right? what's interesting is that there are actually some interesting important innovations inside an AI native database, right? That is not obvious, right? So, what I call obvious is not conventional things like vector search, agents, MCP, knowledge engineering,
knowledge, you know, modeling, and so forth. All those things are pre- are in the previous slide. I'm not going to talk about those things, right? Because I think those are the logical talk about them, so I want to sort of focus on the things that are sort of less obvious, right? That I think that makes AI more effective with using databases. And the three things that I
picked are, first, the converged architecture. Secondly, JSON relational duality, which is very interesting concept. The last thing, which is very important, which is end-to-end security in the database. You know, how do you make the data safe for agents to consume, right? And in this talk, I will use the Oracle AI database as as an example, right? Because this is one that is most feature rich, and I
think it's a very good heuristic to get a to get understanding of what these things look like. And of course, I will try to identify alternatives. So, if for instance, you're not using Oracle, how could you try to accomplish similar objectives? All right. So, I'm going to boil down to sort of what I call the actionable principles, right? When AI is using data, what are the things
you need to do? Number one, you want to keep things simple, right? You want to You want to make it easy easy for the AI to get things right, right? You know, you also want to save work. Because if AI has to do less work, it consumes less tokens and you save money. Okay, very simple. Okay. Next, part of making it easy is that you have to
explain the intention, right? When you have your data modeling and stuff, you explain what your intentions are, right? Don't count on the AI to figure it out. Okay. And again, that's important because you want to You want to make it easy for AI to do the right things. Because when AI does the wrong things and generate lots of code, it's very hard to fix it, right? And
the third thing along this thing is do things that the AI is trained on, right? That means use standard APIs like SQL instead of proprietary query languages and adopt standard patterns that AIs are familiar with, right? And lastly, you want to provide guardrails that cannot be bypassed, right? Because AI can do bad things, intentionally or unintentionally, right? You need to provide strong security. Because again, if you
cannot trust the AI, you cannot use it. And along these lines, I sort of picked some anti-patterns, right? If you look at how database applications are done, there are some misconceptions that are sort of going around, right? First, I see a lot of what I call polyglot sprawl, which is people create multiple databases, you know, for a single application and that creates data silos, duplicate data, and
complex synchronization, right? And this gets to be very very worse when you add AI to each of these databases. Right? Because again, you just proliferate the differences. Weak consistency, you know, when you have all these databases when you move data around, right? That breaks that breaks transaction guarantees, right? Uh and also since you data in multiple locations, that sets up opportunities for data to get out of
sync. And when data gets out of sync, you lose consistency, right? Which leads to wrong data, and wrong data fed to the uh large language models means that you get wrong decisions and wrong actions taken by agents, right? The last thing I see is that it's kind of a brittle security because many times applications develop security enforcements in the application code, right? That makes it easy to
be bypassed and makes it very hard to harden, right? And and therefore, that makes it very risky when you are large language models that directly accessing your data. And so, the principles that we're talking about we're addressing these anti-patterns. The first one is the converged database architecture, right? So, the world of data, this is like say, 15 years ago, was very very simple, right? You had traditional
OLTP and traditional analytics or data warehousing, and they both ran on relational databases, right? And then, since then, many new and specialized data technologies have been introduced, right? There's new new types of data, relational, documents like JSON, spatial, text, new types of analytics, right? Data warehousing, data lakes, graph, streaming data, new workload types, you know, AI of course, geo-distributed, IoTs, blockchain, so applications are now built by
combining can be built by combining specialized databases. But if you consider a restaurant app, it has restaurant listings, it has maps of where the locations are, it has user comments which may be in text, it has geospatial location information, and so forth. So, a single application uses multiple types of data, right? [snorts] And so, if you follow the previous model of using specialized databases, you have to
basically your app has to basically use multiple types of databases, right? And this creates complexity because obviously these databases were never intended to be worked to be used together, right? And that's why you have things like Kafka and stuff to move data around and so forth, right? And this creates data duplication, because as data needs to be present in multiple databases, it needs to be copied and
moved, right? And when you move data and you have multiple copies of the data, you have consistency issues. Because when you update one copy, the other copy gets out of sync, right? And of course, you have to manage different APIs between each of these databases. Since particularly the specialized databases have proprietary APIs that are different, right? And of course, each database implements security policies very differently, so
you have to manage all these differences, right? And the advent of AI makes it far worse. Because because of AI, every single database is adding vector support, everyone, right? So, now everyone is different, everyone has different vector support, and so the differences are getting proliferating even more. And now even the specialized databases are no longer specialized anymore, because they're everybody's trying to be more general. And this
is hard, right? Because now your data's fragmented all over the place, and then your goal is to get large language models to work with your data. If your data is in lots of locations, you just made the large language model's job much harder, right? Making it much harder means it will be it will be harder for it to do the right thing, and it will be more
expensive because they'll do more things to figure out what the right things are. So, what I want you to do is to use really the alternative approach, which is called the converged data architecture, right? So, you you basically make all the data types workloads work together. So, the first is you have to support all the key workload types, right? And so you can support OLTP, graph, IoT,
distributed, you know, analytic data microservices can all work together. So, you know, this sounds really radical, but this is what the Oracle AI database does. We just have a single database engine that can support all these different workload types. And I think that's important because what happens is as new workload types come and go, you can move the workload types to your data and not have to
move your data around. Next, support all the key data types. Okay, again, you know, you support media, spatial, JSON, relational, and so forth. Again, on the same database engine, and since they're part of the same database engine, they can work together. So, a single application against a single database can use all these data types in a single app. because this is part of the same database engine,
it shares a lot of commonality. It has a common high availability architecture, you know, common ways of scaling out, common security, which is really, really important because common security enforcement gives you high security. And of course, common transactions, so you can do transactions between all three data types, multiple workloads to ensure consistency of data. So, so that's the that's that's the that's what the Oracle AI database
does, which is really a converged database engine that supports all the workload types, all the data types, right? Now, it does not mean that you have to do it this way, right? What it does is give you a choice because where before you were always picking specialized databases, now you can say that, well, instead of using, in this case, you know, 12 different specialized databases, I can
replace all of them with the Oracle first database and reduce down to only the special cases that are really, really special. Right? And so, you're not forced to by definition take a fully distributed approach just because of the limitations of the specialized databases. So, the analogy I draw is this. We all carry smartphones today, right? If you think back like before the iPhone came around, you know,
we carried a separate GPS, I had a separate cell phone, I had a separate camera, right? And sometimes we have separate notebook we had we carried separate devices, all specialized devices, right? Now, they've all gone away. Now, they're all features of my single smartphone. Right? And so, this is the idea of the converged architecture. The converged architecture says that instead of using specialized database for every single
purpose, use a general purpose database that can support all the functionality, and then make all the functionality features of the integrated product. Okay? So, the converged database architecture is really the smartphone of data. And the mantra is this, simply make it simple for AI and simple for human developers, right? Because if you can do this and make it simpler for the AI, by definition it's also simpler
for the human developers. And and AI is not going to write all the code. Okay. Now, what if you don't use Oracle AI database? Right? Um I think Oracle is the converged database, right? It is it is the most complete converged database, and that's the quote from ChatGPT, right? And what we see is that every other database is trying to move towards a multi-model approach. Right? You
know, Azure Cosmos DB, SQL Server, Google AlloyDB, they they make a big deal over the about multi-model support, right? But what I see is that a lot of databases have really one primary data model, right? So, for instance, MongoDB, the primary data model is JSON, right? Then the others are really secondary. So, so if we look at a multi-model approach, it's important to make sure that they
support multiple equally powerfully, right? You don't want them to fresh cases models, right? And so, that's number one. So, I think multi-model is definitely what everybody's trying to do, and I think that's a great thing, right? But the thing that the other people are saying they're trying the other vendors are trying to promote is really different database with different workload types. So, for example, you go to
AWS, they have a database for yeah, Redshift for data warehousing. Then OLTP they say use Aurora, right? Then for graph they use different something else, right? And so, so I don't see a lot of convergence in workload types yet, but hopefully that will come. Right? So, if you cannot use a converged database, at least use a multi-model database, right? Make your life lot simpler. All right. 16.
All right. So, that's the first one, converged database. The second one is something we call JSON relational duality, okay? Which is a mouthful to understand. data engineers prefer to use relational tables. You have application data, so you map, you know, objects to relational tables, right? And so, you decompose components into rows in the table in in multiple tables, And relational model brings three free benefits, right? You
access value by data value using SQL instead of hand-coded navigation. This way, when you change the way the data stored or accessed, it doesn't break the applications, right? Also, you normalize the data, so you don't have duplicate copies. There's only one copy of each data element, such that you're guaranteed everything sees the same results, right? And of course, SQL is a standard, which means everybody knows knows
relational models. The other tools do use it, developers use it, AI's are trained on it. That's great. However, you know, developers, many of us don't like prefer document Actually, many of us prefer document models like JSON. You know, why? It's because JSON more easily maps them to application objects. So, if you have purchase order on the left-hand side, I can decompose each of these elements into, you
know, hierarchical documents, if you will, right? And I can do a single get retrieval from the database, get the whole document instead of reading different pieces and putting them together, right? So, it's just more convenient to map them into objects. However, the downside of storing objects JSON documents is that there's duplication, right? Because when you when you have shared data, there's no no concept of pointers to
to normalize tables, right? Therefore, you You duplicate you You data that are duplicated. So, in this case, you have schedules for two students. They happen to take the same classes with the same teachers. Well, guess what? The class information and teaching information has to be duplicated within each student's schedule. Right? This duplicate So, imagine a thousand students with this class, you have a thousand copies of this
data. The same data, right? That means if you want to update the teacher information or the class information, you got to update lots of copies. And when you do that, you have things can go wrong, things can go go stale, it can be inconsistent, and so the current developers that choose or force to choose one or the other and accept the compromises. You choose relational or you
choose document, And what JSON relational duality does, it actually allows you to access the same data both ways, right? So, you can look at your underlying tables, then map them directly to these JSON documents, right? And you can access them either relationally or for JSON, JSON path expressions. Okay? So, now you've eliminated the compromises, the same data can be accessed both ways, right? So, what happens is
if you want to look at it as JSON, even so there's like four different underlying tables, you do a single get operation, you get the JSON document back. Okay? The database takes care of consolidating all the pieces together, And this works with JSON documents as well as graph documents, right? So, that you can actually unify lots of different types relational JSON graph to work together. Okay? So,
that's an interesting concept, which is not only is it a converged database, it's a converged data types, if you will, right? It unifies This actually unifies the data types. Okay. So, there's some interesting things about this. So, number one is that notice when when I drew a picture about how the same data can be accessed using relational access or using document access, right? The key is that
their access They're the the transaction consistent. So, if you have two different sessions, one can be accessed using relational operators, the other can be using JSON operators, and the updates they make will be transaction consistent across both of them. Okay, so that's important. So, you don't wreck your data, if you will, right? And this eliminates source of error, making it safe to unify the It's also faster,
right? Because today, what happens is that most developers use object relational mappers, like Hibernate, right? And then you map relational objects to So, Now, the problems with re- object relational mappings is that you're still doing four different access for and four inline tables. With the JSON relational relative views, you're doing one access to the view, the database maps it all together, and returns one object in one
operation. So, it's just more efficient, And lastly, which is non-obvious, which when you describe the data using these object relational using these uh JSON relational views, you're actually giving the AI more information. You're now you're explaining how the relational tables are being mapped to objects, right? That gives AI more more understanding of the intention of the data modeling, and that helps AI generate correct and better SQL,
right? So, that's sort of the the non-obvious benefit. And again, that the mantra is if it's simpler for AI, it's simpler for human developers, and that's a good thing. Okay. And And so, this guy, Carl Olofson, which is a research VP at the IDC, says this is really the best innovation in in finish lines in 20 years. I I think he's actually wrong. I think this is
the second most important innovation. Yeah, I think AI is is even is is the most important one. Okay. But, this is clearly very important in in this in this technology. Okay. So, the third one is sort of the the the thing that no one likes to talk about, which is security, right? Yeah, because uh you know, so how do you enforce security near the data? So, today,
what we see is that data privacy is frequently managed at the application layer. so, what happens is that this is specialized application this applications have their application logic that validates you that uh basically looks at users and decides what kind of access controls or access privileges users can have and they use that to access databases. So, there are a few database roles like for instance user, administrator,
benefit manager and so forth and then they map users to these these small set of rows rows and they access database, right? And so, each application enforces own security. Right? So, the danger of that of course is that if your data is shared among multiple you have to trust every single one of your apps because the weakest app is because you just have to have one weak
app to expose your data. I mean, that's it, right? Because you have you have just in other words. And and this gets worse as AI comes along because AI particularly agents add new risks, right? Because for instance, the AIs can generally generally arbitrary SQL. Right? So, when you generate arbitrary SQL, they're not actually going against your application modules and so they can actually bypass your controls. Right?
And then we've seen the AIs can can basically bypass guardrails because guardrails are typically just instructions to the AI to say, "Don't do these things." And we've seen the AIs can actually bypass and do those things anyway. Right? And and so so, because of AI, you know, accessing data directly, you know, they're going to bypass your application level controls and and and and protecting data at application
layer just doesn't work because if you access things outside of the application, you know, the controls don't don't take effect. And in fact, you know, security is really the top concern building AI systems, right? Because, you just just think of the liability. If you release release private information about your employees on the you know, you just can't do that, right? It's the main reason that applications implement
security application layer is because data access rules are actually very complicated. Right? So, for instance, if you look at the human resources employee database, they have many interesting things, right? So, for instance, as an employee, you can look at your own data, like your own salary, your own performance goals, work address, home address, and so and you can update your own home address, right? Managers can view
their reports people information except for home address, right? So, you can see that, you know, employees can look at their own data, but not other people's data, right? Managers can update their performance goals, but others can't update their addresses, right? And of course, human resource representatives could have broader access for the organization, right? So, you can see that just in this employee database, there are actually very
complex rules, right? And these are very application specific. So, so this is why, you know, Oracle A database has this concept what I call deep data security, which built app level controls in the database itself, Because the the goal is really to eliminate the need for applications to enforce to do the security policies, right? As you need to be able to express the the policies in the
database. So, the way it works is following, okay? Uh we assume that you have an identity provider, like your cloud identity provider or your global sign single sign on, so forth, and then you log in and you get credentials, right? And then you use the credentials to get the roles and so forth. And so, those things get passed to the database, and the database understands that. Okay?
So, because these credentials are encrypted, so they they can be authenticated and verified to be correct, right? Then, in a database itself, we enforce the access controls using the rows and credentials that are passing by your single sign-on or your or your cloud credentials, right? And furthermore, we we use we allow you to express these application rules for access controls. So, you can actually control for each
row of data who can access data, for which cell of data who can access the data and under what conditions, right? So, this way we can embed the at the at the point in the database itself. And we use the exact identity that's passing when you're logging, right? And so So, what this means is that you no longer have to enforce the access control within the application,
right? You can express it all as database access controls. And so, no matter how you access the database, the access controls are enforced. And that's the key point, because the access controls are enforced at the database itself. So that it doesn't matter whether your applications are misbehaving or you're bypassing the the controls are in place, right? Uh let's see now. I think I will skip over this
part because I'm running short of time. Uh and this is just an example of what the syntax looks like in terms of SQL, you know, in terms of people, the rows, and and so forth, right? So, it's uh and and again, you can see additional stuff. Because again, these rules can be complicated, and so we allow you to declaratively specify who can access these conditions and the
what rows by means, okay? Yeah, I think this is just some stuff I'm not going to go through this, but this is just some examples of AI use cases with retrieval and the generation, you know, and so forth about how how these controls can take place. Um Oh, yes, that's right. So, I'll leave this here, right? Um this feature, it turns out, is Yeah, I was I
was trying to think if you're are using Oracle, right? Of obviously if you are in this situation the easy answer is just use Oracle. Right? But if you can't, um I would say that for instance using PostgreSQL, right? First of all, definitely use row-level security. Right? And then enforce authorization in the database. Okay? You won't have the fine-grained cellular cell level or application level security with Oracle,
but you can do the best you can. So use at least use row-level security, right? And implement the rest with custom logic. Right? You have to There's no choice, right? And you know, um and you need to mask sensitive data. And you should You need to do this centrally at the point of access, which means you should probably do it as stored procedures. Right? And so, um
and of course last one is when you do this kind of stuff, don't forget to audit everything. Because you need to have an audit trail of all the decisions you make so that in case something someone breaks through, you know what happened. Okay. So to summarize, um I talked about the Oracle AI database AI-native database as an example, and I talked about the the sort of the
non-obvious and the dependings that makes AI database development much easier. The first one being the converged right? Second one being the JSON relational duality views. Last one is Enforce access controls where the data is being accessed so that, you know, and not in the application where it can be bypassed and where you are at the mercy of the weakest application. All right. Uh and this is just
just a review of what what I AI database architecture looks like. Just just the stuff I didn't talk about. And so here these are a bunch of QR codes that I think will be interesting. Okay? So first, there's a bunch of live labs, which are actually hands-on examples that you can run through to get get your own experience on how this Uh there's a free version of
Oracle. Okay? That you can just really download and use. And there's free SQL which is a just hosted site that you can just run SQL. Okay? And lastly, I have my email address there in case you have any feedback, suggestions on how to improve this talk. Okay? I think Actually, I think I ran out of time. So, thank you very much. >> [applause]
