Future-proofing your applications with AWS databases

Please welcome Vice President, Relational Database Engines, AWS Raul Peralta.

Hey, everybody. Thank you so much for coming to re:Invent. Thank you for coming to this session. I'm Raul Peralta. I'm the VP of Aurora and Redshift our relational database engines at AWS. I'm super excited to speak with you all about our vision and then also share the stage with some co presenters, Jeff Carter, who's the VP of Relational Databases, uh non relational databases and migrations, Meraz Murali, who's from IBM and Gail Raul from Akamai.

So, what we're here to talk about today is to take you through a journey that really starts with acknowledging that we live in a time of change. You know, especially the last few years, we've seen a ton of change in all our businesses, our lives in general. And you know, we understand that it's super important for us to be able to embrace change. It's a precondition for progress and change also doesn't have to be disruptive. We've made lots of investments in technology. We know all of you have invested a ton of time and energy into your technology platforms, your databases, you want to embrace change while making sure that you don't disrupt what's working today. You've got to run the business, serve your customers, uh, and meet all of the needs. And the good news is that we can do this. We can embrace change, embrace progress and do it without disrupting the things that we rely on and need to work in a bulletproof way today and change is inevitable.

So, we've got a plan for it now at AWS, we've been innovating in databases. Uh really, we began in 2009 with RDS. I've been lucky enough to have gotten to work on many of these things. I joined the company in 2011. I've been in the data space throughout and I got to launch Redshift at the first re:Invent back in 2012. It's just been incredibly fun to be on this journey really with all of you, it's the pace of progress has been tremendous and we've done it together. Your feedback and input has really helped us innovate and to help build things that really matter to all of you and to us and really cloud infrastructure marked a sea change in how we build technology. It made possible things like seamless capacity, scaling a paper use model. But these innovations also translated into databases with manage relational databases, dy Dynamo DB which provides single digit millisecond response at pretty much any scale.

And those of you in the data space know that even though this technology was invented in the sixties, the pace of innovation has continued to accelerate. And you know, the thing that that matters the most here is that we want to innovate with you and make sure we open up the possibilities that are needed to adapt to the world as it evolves.

And so when it comes to how we think about the investments that we're making in databases and data management, really, we want to keep data at the center of it. Data is the focus. We want to give you a way to really think about your data in an abstracted way and not focus so much on the systems that underlie that we want to abstract that way away with innovations like cus technology using things like auto scaling and machine learning to help innovate on your behalf.

And you know, data is everywhere. We understand that you have data in AWS, you have data in on premise environments, in SaaS applications in other providers. We want you to be able to connect to catalog query and govern all your data no matter where it lives and we're investing accordingly. And I'll talk more about that in a second.

Another important part is increasingly all our customers are thinking about really what are their business objectives. You want to think about how to define your goals, how they relate to performance or cost or SLA and have the system underneath it all adapt to those goals and make decisions on your behalf within the constraints that you specify, so that you're spending less time directly and imperatively managing the underlying systems and machine learning will be a big part of this both in terms of how we operate. But also, as you've heard over the past few days, things like AI generated SQL and Q for SQL and Redshift the ability to use natural language to generate data and ETL pipelines. This is going to be an increasing part of the investments that you see from us.

And we're also going to figure out how to automatically optimize the systems that you rely on for performance and speed and scale and cost. And I don't know if you caught Peter's keynote on Monday night, but he talked about some of the work that we've done with AI scaling and Redshift that can adapt to query shapes, query sizes and can take into account your preferences around always scaling even when it might not be super linear or you can optimize for budget and the system will be more conservative only scaling when we know we can be cost neutral or save you money. And the system does that automatically and adaptively. So this is a big part of the investments that you'll see from us as we go forward.

And really the way we see the world evolving is that you will have an access layer that talks through an intelligent fabric to the services underneath. And this will allow you to interact via an API or your SQL query interface or natural languages. And underneath the individual services will be interconnected. We absolutely believe in using the right tool for the right job. That's the way you get the best balance of performance and cost and functionality. And we want to interconnect these in a way using our investments in things like zero ETL so that you can operate in a more intuitive and declarative way on top of your data. And we take care of optimizing everything underneath and you can see these investments.

Um we've been talking about them over the past couple of days. There'll be more announcements over the course of re:Invent and we'll be continuing to invest in this space. Another trend that we see that also informs how we're thinking is that as we're seeing new tooling being developed, the range of people that can build applications that interact with data is expanding dramatically and so with generative AI and low code and no code ways of operating more and more people are able to write apps that work with data.

I don't know how many of you have played with Party Rock, which we launched a few weeks ago. I see a few hands there and that's a great way as well to experiment. And really what this means is more applications are going to get written data is diverse. The people in your organizations work in various parts of them. And they're going to want to be able to connect to that data in multiple ways. And so seamless integration of data with zero ETL will be increasingly important.

And as you know, we announced our the start of this vision last year, we were generally available with Aurora, my SQL to Redshift and had three more announcements around zero ETL over the past couple of days. And the goal is to allow data to flow in a seamless way so that users can focus on building the apps and the queries that they want and not have to worry about how the data that serves those apps gets there reliably and quickly.

And when it comes to zero ETL, the reason we invested in this space is that anyone who's worked with moving data around knows is challenging. It's expensive and cumbersome to build and maintain ETL jobs. Often they're brittle. If something changes, you have new columns, different things need to get moved around. You've got to go back through the dev test production cycle and get data into the right places. Manual scaling of these pipelines is challenging. If you have a spike in the markets. If you're a financial services company, you've got a plan for that and that's not always possible and stale views can lead to data being missed or insights and opportunities not showing up when you want them to.

And so with direct integration between our AWS services. We're connecting the dots between streaming and transactional systems and analytic and machine learning systems so that you can get that data whenever it's created as quickly as possible. And why do we care about this? Well, the reason that we care and when we talk to all of you, you all care is because what's happening is when data is created, either an event occurs in the world or a transaction gets executed. You want to be able to use that data in analysis quickly and with zero ETL to Redshift. For example, we can get data from Aurora at a million transactions a minute into a Redshift for its advanced SQL analytics in under 15 seconds on average.

And then once you've got it there, you want to be able to have that be integrated with machine learning. So you can run predictions or use it to build generative responses as quickly as possible. And so connecting the dots between these systems allow us to go from event to analysis to prediction. And then once you have that prediction, you can personalize, customize the interaction with your customer and then repeat the cycle. And the faster we can go through this loop, the faster we can all learn and iterate and improve our customer experience or find efficiencies in the business. And that's really why we're trying to focus on this is to make it easier and easier for all of you to get value out of your data.

And so we've been talking a lot about integration between our services. You can expect us to continue to do this and we want all of the services that we offer to interconnect in ways that are logical. So you can just focus on operating on your data and not on the plumbing in between these services.

Now, as your data gets connected, you're gonna want to keep track of it, you need to govern it. And uh one of the, one of the quotes i really like is uh discipline equals freedom. So contrary to popular belief, if you have good governance, you can actually move faster because you can set rules in place and then let people be set free to iterate and find value from data.

And so with DataZone data is really set free, you can set guidelines, you can understand where all your data lives in AWS and outside. You can make it easy to set, build catalogs of business, highly curated business data and then create projects around which people can collaborate. And so what you have is a data first view that's well governed across multiple sources and the ability for the right people to come together and use that data to drive business value.

In addition to governance, we're really trying to make the folks that work with data more productive. And so with Q for business intelligence, you can ask questions of your data, get back automated visualizations with integration with Glue. You can create data pipelines using AI. And again, this is a great application of using generative AI and large language models to facilitate the flow of data.

And then Swami announced earlier today in his keynote Amazon Q with generative SQL capabilities and Redshifts. And here you can have a multi pasts conversation with the system and it will help you design complex queries that uh that you can then share subsequently within the organization. So the goal is to really drive productivity on behalf of folks working with data.

And on the operational side, what we're also investing in is automatically optimizing for performance and cost. I can guarantee that every single person in this room would like our systems to run faster and to get lower the average cost per unit work. And so that's something that we're very focused on. We're using sophisticated machine learning models to really understand your workload. We want to get business objectives from you, those we can't discern.

And so for example, with the Redshift services AutoScale you're able to specify where on the spectrum of performance and cost priority you want to, you want to live and the system will make scaling decisions on your behalf to live up to those objectives. And this is something that we feel very passionately about and it's something where our scale gives us a real opportunity to innovate on your behalf.

And again, the goal is to make sure that you don't have to do any work. This just happens after you've declared your objectives and we're really just getting started. But, you know, i want to talk as well about some things that we've been releasing over the past year in addition to the vision.

So with Graviton 3, you get to have your cake eat it and it comes with a cherry on top. Things are faster, it costs less and it uses less energy. It's really rare in technology to not have to make tradeoffs. But Graviton is a huge winner for all of our customers. And we highly recommend you take a look at it if you haven't already.

When it comes to databases, we've been investing rapidly and deeply in our relational platform. And you can see that we've got with Amazon Aurora, we announce IO optimized which provides a very cost-effective platform for IO intensive workloads with SQL Server. We've got RDS custom for SQL Server, bring your own media that lets you use your, your own media, installation files, but get all the benefits of managing of management that RDS provides with Vector databases. We've enabled PG vector support in Amazon, Aurora, Postgres and RDS, Postgres. And this goes back to allowing you to future proof. You can build on the things you have. If you've already been big Postgres customers, you can enable PG vector and then start to build on that, on that for generative AI workloads and with RDS multi with two standbys, you can actually get minor version upgrades in under a second when using RDS proxy.

So this again allows you to take advantage of what's coming without disrupting what's working today. Similarly, on the non-real front, we've been hard at work. And so with DynamoDB, you've got incremental export to S3. DocumentDB provides an IO optimized capability as well for IO intensive workloads with DocumentDB, you also get the ability to integrate with SageMaker and LM. So you can run machine learning and use generative techniques with the documents that you're stored in it.

And with ElasticCache, the team has been really innovating on scale and throughput and now they're able to deliver 1 million requests per second per node with Redis 7.1 that's 500 million requests per second in a single cluster, half a billion requests per second. It's just a staggering amount of throughput all while remaining completely 100% compatible with open-source Redis, which is an API that customers love for in-memory workloads.

So really our goal is to make sure that you have a comprehensive set of services for your data foundation. Data is your differentiator in this world in, in what we're doing with generative AI is making the best models available to all customers. And if everyone has access to all the models, the things that will differentiate you and allow you to build unique applications are all powered by your data. And that's why the investment in your data foundation is so important and we want to make it easy for you to connect the data that's in your various services and then act on it all while focusing on your business objectives. How do you grow your business? How do you find new efficiencies?

And so with that, I'd like to welcome Jeff Carter, my colleague to the stage to drive into these in a bit more detail. Thank you very much. It's great to have you here.

Good afternoon. I'm Jeff and I just wanted to say thank you all for being here. And I also wanted to do a reach out and a thank you to all of the teams that helped develop the software that we're going to talk about today, so some great work and I want to make sure that they all get recognized as well in my section.

We're going to start by talking about comprehensive and it's going to build on Raul's last slide. And we're going to talk about how we have a complete portfolio of different databases. And if there's ever anything or a technology you think that we need to have that we don't have, let's have that discussion, then we're going to talk a little bit about integrated, we'll touch on governance and then we'll spend a little bit more time on enhancing AWS services with generative AI so with that, let's get started from the relational database perspective in diving into relational and non-real.

These are our operational databases or our transaction processing databases. We do have a broad portfolio and we began this week, we had 15 and as we end this week, we will have 17 different offerings in this space. So Amazon Aurora is our open-source enhanced offering with MySQL and Postgres. We have two different or three different RDS engines that are open source and two as we start the week that are commercial and we'll talk more about that in the sec. And then we have our purpose-built offerings. These ad have excellent price performance for their specific purposes and are able to scale to incredible heights.

This week, we're going to announce two new offerings. The first is going to be in the RDS space and the second is going to be with Amazon Neptune. So the first thing that we're going to talk about is an announcement that we made a couple of days ago and that is IBM Db2 in the Amazon RDS portfolio. We've had many customers request for this and now we have even more offerings where you can bring your data to RDS and have it be managed by our infrastructure with RDS Db2. You're going to be able to create a Db2 database in just minutes and to come and tell us more about this. I would like to introduce Minas Morali who is a VP of Product Management for IBM for Db2. So, Minas

All right, Minaj, can you tell us a little bit about IBM and DB2?

All right. So DB2 is a relational database with over 30 years of innovation and it runs some of the world's most mission critical workloads. We have over 11,000 customers that have entrusted their data to this powerful database engine with some of the top leaders in financial services, manufacturing retail health care and many more.

The top 10 banks in the world today run DB2, nine out of the 10 top manufacturing customers today run DB2, 76 out of the Fortune 100 companies run DB2. So you can imagine the scale at which these mission critical workloads run on DB2 on a daily basis.

In fact, if you used your credit card this morning to, to buy a coffee or to check your bank balance, chances are that that transaction run through a DB2 database.

So to summarize DB2 is really the invisible workhorse of the modern economy. In announcing DB2, we're going to give you all of the services that you expect with an RDS engine. And one of the things I really like about this is the fact that if you know RDS, it's going to feel very much like any other RDS engine, we're going to do the provisioning, we can scale up and scale down instances, we can help with the backups. All of the things that you would expect the high availability and the multi AZ implementation are all part of the, the DB2 solution with, with RDS.

The other thing I like about it is if you know, and love DB2, the moment that you log into the database, you're going to recognize that this is the tbd b two that you have been using in your shop.

Absolutely. And it's not just pure play DB2 workloads, right? DB2 is highly compatible with Oracle databases, which makes DB2 a great solution for customers that are looking to consolidate a variety of workloads into a single database engine.

Some of the other benefits that rds DB2 brings to our to our joint customers is full integration with the AWS ecosystem, IAK, MS, CloudWatch, S3 and so many other services that make it easy for customers to, to integrate DB2 into their existing applications that are, that are running on AWS.

So with this launch, our entire set of OLTP and OLAP commercial databases are now on AWS as a fully managed service. And what this means for customers is that it's really quick and easy for them to take their OLTP data from RDS DB2 transform it and make it available for analytics and AI a lot of the applications, a lot of the IBM software solutions offerings that we have today um have announced support for RDS DB2 including Watson X Watson X dot data, which is our new AI powered lake house Cognos Analytics, which is our business intelligence solution, Sterling Order Management.

Um OpenPages. In fact, every new SaaS application that is being developed for AWS, the plan is for it to be backed by DB2 RDS on DB2 as its database as its database.

Um and finally, you know, the joint migration tooling that our teams have worked on uh will really benefit customers to uh you know, to ease the transition from an on prem environment to uh to RDS.

So I just wanted to say thank you both for you and your team. You have been great partners and we look forward to serving our mutual customers.

Likewise, thank you, Jeff.

All right. The second announcement that we're going to focus on today for expanding our portfolio is in is with Amazon Neptune. Neptune within AWS is synonymous with graph. And one of the things that we're going to be doing with Neptune is we're going to be taking it, which currently it refers to a specific database product. And we're going to elevate Amazon Neptune to be a brand name and we're going to have multiple products underneath it.

So today, the product that we have known as Neptune is going to be renamed as the Amazon Neptune database and its focus is going to be on transactional workloads in the graph space. And what we are announcing is Amazon Neptune analytics. And we'll talk more about that in just a moment focusing in on the database portion of this Amazon Neptune is a graph database and it has many use cases including things like customer 360 fraud detection and improving IT security.

And we have all of those operating at scale for many different companies. If you think about what I'm trying to say with transactional workloads, if you were looking at a social graph, a transactional example of that would be if you go to the social graph and you say for this individual who are 10 people that are associated or connected to this individual, that would be an example of an operational query. And Neptune is fantastic at doing very high numbers of these in parallel, but there's a slightly different use case and that is why we're introducing Amazon Neptune analytics and in the, the different use case, what we're doing is we're focusing in on analytics and using in-memory performance to be able to do very high-speed analytics.

So with this, you'll be able to do tens of billions of connections and get up to adx faster results than you would be with other leading products. So this will allow you to scan your entire analytics infrastructure. So where the other example for operational was looking at one customer and the people who are connected to it a different type of query would be. What if I want to look through my entire social graph and find the biggest influencers within that graph.

That's the equivalent in the database world of a full table scan. And so Amazon Neptune analytics by having the data in memory and it is a persistent, we have taken the file systems that we use for things like DynamoDB and, and MemoryDB and we've included that in the solution. So we're going to get very high-performance reads, very high-performance rights and very, very, very fast analytics.

And so you can also use this for basically temporal applications where or ephemeral applications where you load data into it, ask a few queries and then shut it down and return it into the, the EC2 pool of instances.

So here we are, we've added two new products into our, our portfolio RDS DB2 in the commercial relational space. And we've added Amazon Nep2 analytics into our purpose-built space.

Now, not only are we adding new, we're also making serious investments in improving our existing ones. And while we have many different examples of that and Raul gave some in the prior section, I wanted to focus in on two in this particular section. And the first is going to be the Amazon Aurora database with its limitless database capabilities. And the second is with Elastic Cache Cerberus.

With Amazon Aurora, we can scale to very large databases, but one of the things that's common in the industry today is more and more data and more and more I/O throughput. And we do see databases that are growing beyond the capabilities of a single instance. And so what an Amazon Aurora database is going to a limitless database is going to allow us to do is effectively what's known in the industry as a sharding solution.

So you'll be able to pick a key and you'll be able to hash it. And we are going to distribute the data across a series of Aurora instances. And one of the things that's key about this is we are using Amazon Aurora Serverless V2 as the building block for the different shards. And that's really important because each of the shards may be getting a different portion of the workload.

And with Amazon Serverless Aurora scaling up and down independently for each of the shards, you'll get the performance that you need when you're using that shard a lot. But when you're not using that shard a lot, we will automatically scale it down and you won't be paying for the infrastructure.

So at a high level, client applications will have a single point to connect to, there will be a router that will take a look at an individual query or an insert statement or update and it will direct it to the appropriate shard and then that will be done to the storage. And so this will all be done automatically. And your applications will be able to look at this as a seamless single database and we'll be spreading the workload across the different shards and it does support both distributed transactions and queries.

And this is all about being able to scale memory, being able to scale compute and being able to scale I/O throughput.

The next one I'm super excited about, you know, when I talk to customers about creating a cache for some reason, I never have anyone argue with me. When I say it can be hard to configure a cache, you need to figure out how much data you're going to have over time and you need to figure out how many process requests you're going to have and you can over provision and be able to guarantee really good performance. But that's not always frugal or you can partition, you can provision on the lower side and that is more frugal, but you may get into a situation where you're not getting the performance that you need at a critical critical point in time.

And so the beauty of a Amazon Elastic Cache Serverless is you don't have to decide upfront and the system is going to scale up and down based on the workload and the data that you have in the system and it's going to do it all automatically.

Raul talked about with Redis 7.1. The, the, one of the latest versions we're able to get up to a million transactions per second per instance. And we can have up to 500 instances in an Elastic Cache cluster and we can do it with four nines of availability.

So with up to 500 million transactions per second, I think we'll have the vast majority of the marketplace covered. If you have an application that needs more than that. Please come talk to me and we'll work together on it similar to the other, what we saw with Aurora Serverless, we're going to have many client applications, they're going to come into a caching endpoint and we're going to distribute it across the the environment.

And as your system starts to add data and queries into the system, we can first scale up within a single instance and then we can scale out across multiple instances effectively doing a type of sharding like we talked about with Aurora. And so we'll scale up based on your workload. And then if there's a later point in time where you're not using all of these resources, we will automatically scale it down.

We are also able to use this infrastructure for things like automatic and transparent software patching so that we can be doing updates either on the the operating system or on the Redis system. And we can be doing that transparently on your workloads. So really simplifies the management of caches.

Now, I'd like to talk a little bit about the integrated and this is going to build on some of what Raul included in the intro and the strategy section. I'm sure all of you are going to agree that detecting fraud today now is better than detecting it later. Similarly, if you're going to serve an online ad, it's probably better to do it soon and do it before the person buys something as opposed to doing it after the person buys something.

Or in terms of supply chain optimization, if you're running out of a good and you need to have it replenished, I think we would all agree that it's better to do it sooner. So in all of these different use cases, there's reasons why we want to get the data over into the analytic environment as fast as we possibly can.

And that's why we are introducing and we have launched Amazon Aurora, MySQL feeding data in real time into an Amazon Redshift system. And while we are here this week, we are announcing three new pieces into our zero TL integrations. And that's Aurora Postgres into Redshift, Amazon RDS for MySQL into Redshift and Amazon DynamoDB into Redshift.

So all of these are zero TL with no pipelines, we could have multiple engines feeding a single Redshift instance. So if you can imagine if you have a lot of fulfillment centers and you want to have all of them writing into one Redshift instance. So you can see inventory across all of your fulfillment centers, this solution will work very transparently for that.

The other thing is it's very high performance and we get near real time performance on on our core analytics. Another type of analytics is necessary and we can talk about turning analytics into search as a different form of analytics. And for some of our non-real databases, things like key value stores or document DB and document data stores, sometimes it's easier because they have variable fields to be able to put that into a format that we would be able to do different forms of search on.

And so that conclude things like vector, full text, neural geospatial. And what we're announcing now is Amazon DynamoDB zero TL into Amazon OpenSearch. So this allows DynamoDB to be able to have its change data capture flows automatically going into OpenSearch. So we can do things on DynamoDB data like tech search vector search, hybrid search. And more so, and this is being released now.

Now the last thing on this is governance and Raul talked about that in the opening section. Governance is a key topic for us and it's something that we will be talking more about it, but we've chosen not to do it in this presentation. If you would like to learn even more about our governance, I would highly encourage you to talk, come to G2's presentation like this tomorrow where he will be going depth into governance into data zones.

With that, I'm in a transition. And I would like to invite out Gail Fredericks. She is here from Heroku to talk about the integrations that the Heroku team has done with Amazon Aurora.

A decade ago, Heroku pioneered database as a service and today we have one of the largest database fleets in the world. Now, I'm going to tell you about how we partnered with AWS to modernize that fleet in the age of AI. But first a little bit about Heroku.

At Heroku, we believe that developer experience in the cloud should be opinionated and highly productive with Heroku deploying and managing your apps in the cloud should be frictionless. A magical developer experience is in our DNA and it shows with our customer scale.

Heroku is one of the largest platform as a service providers. Today, we handle more than 60 billion requests a day. Our customers use Heroku's managed databases in their apps without worrying about decisions that don't differentiate their business. We take care of the infrastructure so our customers can focus on what they do best building software that it solves problems.

Heroku invented 12 factor principles for app development in the cloud. We trailblazed software as a service. So we understand the significance of stateless apps and dependable data stores with Heroku Postgres. Our customers get access to trusted secure and highly available databases optimized for high-scale production use, creating and connecting a Heroku Postgres database to your app is as simple as just one command.

Innovation is what we do at Heroku. We are dedicated to simplifying the cloud by managing dev ops and infrastructure. So our customers can focus on their groundbreaking solutions internally. Heroku engineers enjoy the same productivity.

Do you know most of Heroku is deployed on Heroku? And that is how our database engineers deliver new Postgres experiences swiftly and efficiently. And that's how we delivered our recent launch of PG Vector with PG Vector. You can transform your trusted Heroku database into a vector database enabling vector similarity searches. That's a crucial part of integrating AI and LLMs into your applications.

Now, with rapidly evolving technology, especially the influx of AI and data, Heroku needs to take our managed Postgres to the next level. For example, our customers are asking us to improve our database elasticity. And that is why we partnered with AWS to work with a team of experts just like us.

When looking for alternatives to self managing our Heroku Postgres infrastructure, Heroku selected Amazon Aurora because of its exceptional performance and its availability at global scale. Aurora provides out of the box, automatic dissing enterprise grade fault tolerance and easy replication. And we know our partners on the Aurora team share Heroku's commitment to customer trust.

So what does Amazon Aurora mean for Heroku customers? Well, we are migrating our entire Heroku Postgres fleet to Amazon Aurora, Aurora decouples compute and disk empowering our customers to scale and extend their databases according to their needs. While still enjoying the simplicity of Heroku, our fully-managed database solution allows customers to expand into data analytics and AI ushering in a new era of possibilities.

Amazon Aurora is a very important addition to Heroku's data platform. Now, our customer data is safeguarded with automatic multi AZ replication ensuring resilience against local disruptions. And our customers are also asking for multiregional redundancy. The fact that Aurora Global Database already supports that is a testament to our shared value of data security.

And Heroku Postgres on Amazon Aurora supports more database connections and a wider variety of Postgres extensions. Behind the scenes, we are gearing up to revolutionize how our customers interact with Heroku products. But don't worry, we will always maintain the simplicity and magic that Heroku is known for. It's still the same single line of code to create a Heroku Postgres instance on Amazon Aurora, we're starting this migration with Heroku's Postgres Essentials tier.

This transition to Amazon Aurora as our backing infrastructure is the right choice. And here's why: Aurora's separation of compute and storage provides our customers with cost flexibility and it scales all the way up to 128 TB. A TB is about 1.1 times a terabyte. Aurora also provides three times the throughput on similar hardware as compared to upstream Postgres and database upgrades just take a couple of seconds.

We're thrilled to announce Heroku Postgres on Amazon Aurora is in pilot. We've onboarded our first customer in Japan, Levanest. They are an education technology consultancy and they are very excited to see the improved performance.

Looking ahead, we have set an ambitious goal for the next year, Heroku will migrate its entire fleet to the Amazon Aurora platform. We're starting...

Our partnership with Amazon Aurora enables Heroku to bring Postgres innovations to market quickly. Today on Aurora Heroku provides greater data throughput, more database connections, a wider variety of Postgres extensions and multi AZ replication

we are only getting started with this new chapter of hiku. thank you very much.

all right. thank you, gail

raul and i are really blessed, blessed to have such two great partnerships to be able to share with you today. they have both been really fantastic to work with and we're excited about the capabilities we're bringing to the environment.

all right. now, in these sessions, we're supposed to be doing a deep dive. and so today we're going to do a deep dive into how we are working to make generative a i available. and we're going to give you an example of how we're working with the operational databases to, to really accelerate generative a i.

so when we look at the iceberg, yep, generative a i, there's a lot above the water, but i think we all are recognizing that there's a lot below the water line as well. so we need to deal with the foundational models. we're going to want to tailor those foundational models with our corporate data. we're going to need a vector database, either a specific vector database or one that has been able enabled with vector database capabilities that's typically called vss or vectorized similarity search. and then we're also going to talk briefly about agents to be able to automate some of this work.

the key here and raul touched on this earlier is your data is your differentiator. if you're just using an lm, you're going to be getting the same answers as any other company and your corporations and your enterprises have lots of valuable information that you're going to want to bring to bear into this environment.

so we're going to start with a very simple example. today we're going to work at a shoe store that's online and we have an individual who is coming into our website and they simply say that they have bought a pair of shoes and they would like to exchange them for a different color. and so we're going to talk about some of the things that need to go on to be able to enable this and to do it in the gen a world.

and so ultimately, what we're going to need to do here is a series of steps where we're going to define some orchestration about how we want the, the generative model and the interaction with the customer to flow. we're going to configure the foundational model to access data sources. and this is where the operational databases are going to come in in two different ways. we're going to use different technologies to do the workflow and complete a series of action steps to enable the person to exchange their shoes. and we'll touch on. we need to make sure that this is production and some of the things that we need to do in the cloud to make sure that this is a managed and well functioning solution.

step one is let's define our workflow. we're going to want to do things like chat with the customer, perhaps ask them to gather their order history because we're going to want to validate that the person actually bought the shoes. we're going to look up the customer order. we're going to want to get information on what is the replacement shoe that they're going to want to get. and we're going to need to check that we actually have inventory of that before we agree to, to replace the shoes. and so this is the workflow that we're going to do.

and here's where the operational database starts to come in is in this workflow. we're going to have two different types of interactions that are generative abased. the first one is fairly simple and it's a fact, look up the shoes that we want to do the replacement with. do we have those shoes in stock? and the second one is a vector similarity search. and this is really, i think more of what you're probably think about in terms of generative a i and what we're going to do is we're going to have a policy repository. these are just some documents they may already exist on your webpage that are going to describe how we're going to interact and what our commitments are for the customer. and we're going to use those to do vector similarity search in combination with the foundational model so that we can make the decision to replace the shoes.

now, the other term i want to introduce is retrieval, augmented generation, also known as rag. and in this, these workflows, both of these, the fact looked up and the vss are forms of rag, but rag is basically how do we take our corporate information and include it in the workload that's going on with the foundational model.

now, one of the things that we're going to want to do and there are multiple ways to do this in this example, we're showing it being done with lambdas. i'd also encourage you if you've been listening to some of the different bedrock announcements, there was something called bed bedrock agents, but effectively, what we want to do is take these individual steps and break them down into a series of what will ultimately be api calls where we're just going to do simple things.

so one of the examples and this is the simple one is we need to check whether or not we have inventory on the shoe we want to replace. and that can be done here with either lambdas or bedrock agents.

and finally, in this example, we do want to make sure that we're hosting it in the cloud securely. and i'm sure you're all familiar with these steps. i'm going to focus in on the role of operational databases in the generative a i application and specifically here, let's talk more about the vector similarity search implications.

so in our example, we've got some corporate documents and these could be training manuals, these could be external web pages that you already have available to your customer, but it's information that is specific to your enterprise and and that you want incorporated into and work with the foundational model in this process.

now underneath the covers in the video demo that i'm going to show you here in a moment. here is kind of at a high level, some of the different things that are happening.

the first is we're going to take information and these are the are are documents that we're going to be reading and we can do things like we want to read in the product catalog, we want to read in our returns policy, our training manuals and perhaps other policy docs in the the implementation that we're talking about bedrock is automatically going to take those documents and it's going to do a lot of the heavy lifting. one of the first things of heavy lifting is we're going to do some of the chunking and we're going to look for keywords that were like sandals and high heels that are in the dock. and then we're going to run those through any of your favorite foundational models. and we've got tightened and clawed and other examples here. and the output of that process is going to be a series of vectors and vectors are simply numbers that represent what's going on in the document. but the vss capability is all about going to be manipulating those numbers.

the second thing is those numbers are vectors. and i'm going to use the phrase an in dimensional space here on the picture. we're showing a three dimensional space because i don't know how to draw an in dimensional space, but i do know how to draw a three dimensional space. but what i'm trying to get across here is that these dimensions can be completely unrelated. so in one, we have different types of shoes, we have different colors of shoes, but then we also have policy docks. when we do vector similarity search, it is going to look for the nearest neighbors in an in dimensional space. so again, this example could be three, but we could have 2030 50 different dimensions on any particular thing that we're we're looking through. and the vector space search is going to be looking for the nearest neighbor.

now, i'm going to show you a two minute demo here in just a moment. but this is a high level view of what's going on inside that demo. we're going to read the docs, we're going to chunk and vector, we're going to put the documents in a vector enabled database. and in the example, it's going to be aurora postgres with pg vector. and then the embedding model is going to combine together what's in the foundational model of your choosing with the vector with the vectors that are stored in the vector database.

so with that as kind of an introduction, let me cut to the demo one more.

let's look at it from the customer perspective, the customers on the left-hand side here, they're interacting with some form of a chatbot. the query is coming into the environment bedrock is combining together amazon aurora and the vectors that are stored there along with the foundational model of your choosing. and it's creating a response with that.

let's go ahead and watch the demo to set up an amazon bedrock knowledge base for amazon aurora. you first have to provide basic information about your knowledge base including its name. next, select an amazon s3 bucket that contains your documents. amazon bedrock will automatically chunk and generate vector embeddings from your documents and synchronize them into your amazon aurora cluster. next select aurora as your vector store, you will need to provide information about your aurora cluster, including your cluster arn. you will also need to provide information about your database that tells bedrock how to connect and store the generated embedding data into your aurora cluster. next, enter the column names that will store the vectors and text chunks. this provides bedrock with target fields for storing the embedding data generated from your documents, review the information and create your knowledge base. amazon bedrock will now generate embeddings from data stored in your amazon s3 bucket and store the text chunks and embeddings in your amazon aurora cluster. you can track the progress of the synchronization from your knowledge based dashboard including how many source files have been synchronized to your aurora cluster.

let's see the knowledge base in action. in the lower right hand corner, you can chat with a bedrock agent to answer a question about information that exists in your aurora cluster. the bedrock agent will automatically query the amazon aurora cluster to provide an answer to the question there.

you have it. now you see now you can add amazon aurora as an amazon bedrock knowledge base and use amazon bedrock agents for your retrieval augmented generation workflows with your amazon aurora cluster.

so in just a couple of minutes, we gave the location of a shared drive. in this case, an s3 bucket that had a handful of documents in it. we read those in we vectorized them, we put them in a we combined them with a large language model of your choosing. we gave you a prompt so that you could select your favorite a vss enabled database. and we in less than two minutes, we read in all of those documents did the process. and then we were able to ask a question that was only answerable by taking both the magic of the lm and combining it with the policy documents that we read in from the shared drive. so pretty cool stuff.

now, there are many different vector enabled databases out there in the marketplace today. they're all great. we're going to give you and from a native us perspective, we're going to give you choice and you're welcome to choose the one that you you like. but i will tell you one of the things that we're hearing consistently from customers is that there's some reasons that they want to use the databases that they're already using.

so one you're already familiar with it. two, you don't have to have extra licensing. three. it reduces the need to sync data between different systems by storing the data with the ground truth. and so the vector embeddings can be right alongside the core data. and finally, you're not going to return the vector numbers to your end consumer. and so at some point, you're going to need to translate them back into the text that you had originally. and so by storing them with that ground truth data, that's going to be an easier process and and a faster process.

that's why across our portfolio, we are working to add vss capabilities to all of our different databases. and so while we're working on that, while we are here this week, we have successfully done that with seven different offerings.

so we've got amazon opensearch, aurora postgres with pg vector rds, postgres with pg vector. amazon memorydb is being announced and is in preview. amazon neptune analytics is is available and amazon documentdb is also in preview and last but not least, amazon dynamodb can zero tl the data over to opensearch and we can do the vss searching on dynamo db data in opensearch and all of these are available now either in preview or generally available.

one thing i want to get across is that this is a super rapidly changing space and the answers that we give you today may not be the right answer, six months from now, maybe not even three months from now. and so one example of that is if we go back just 90 days and what we've done over the last 90 days, amazon optimized reads with pg vector has increased the performance of the vss workloads on aurora not 20% improvement, 20 x improvement inside the last 90 days. and the point i'm trying to get across here is that this is a super rapidly changing space and i don't expect that to change in the short term.

one of the other things that, that we've talked about in past years in this presentation is how do we get data over into aws? um and into these different database engines and our tooling for that, our primary tooling is a service called data migration services or dms. in each year we give an update. and this year we've got over 1 million different databases have been transferred either outside of aws into aws or aws to aws using this technology and the pace and the rate of these migrations is only increasing. and so so far, this year, we've had over 340,000 migrations using this to link. so this is a big business for us and we are doing it absolutely at scale.

but i want, we know that we have areas to improve here and i wanted to talk about kind of the vision for this space and so very, very briefly, one we are working on tooling, we call it fleet advisor that you can put in your environment. and if you have databases that you want to migrate and perhaps whether it's with it, using the same technology as source and target or using different technologies, fleet advisor can look through your portfolio of databases, it can look at what they are doing and it can give you t-shirt sizing of small, medium and large about how much effort it's going to be. and it can tell you if you move to technology x, it's going to be a small amount of work or if you move to technology, y, it's going to be a larger amount of work. and so it's great for looking at your portfolio of databases and figuring out how you might prioritize and how much effort is involved.

the second step is dms is the data migration. this is what we use to move the data and we're working on automation that will automatically open up your source database, figure out all of the tables that need to be transferred and then start to transfer all of that data in the background. while also sct which in the past has been a pc based application is now a web service. and the schema conversion tool sct can now be looking at the queries that you're running on your system and converting them in the background. and we're working on improving our both the ability to test both the data and the output of queries to make sure that you're getting 100% what you expect on the target system before you cut over to it. and so this is the path that we're working to automate with the, the tools that we have today.

another thing that i i'm super proud with the team on is that we are doing our absolute best to be good contributors to the open-source communities that we participate in. and so this year, we are announcing that just, just so far this year, we have made over 550 accepted contributions to the communities in the database land of postgres. my sequel, maria db and redis, this continues to be a huge area of investment. we know all of you like these, these open-source technologies. we very much appreciate being able to offer them in the aws environment and we want to be good stewards and we're constantly giving back to these different communities.

so as we wrap up here, let's talk briefly about what were the things that we just talked about and announced what we did rds for db two. we did amazon neptune analytics for high-speed analytics on your graph database. we talked about amazon aurora limitless database for databases of significant scale elastic cache, servius to make it easy for you to create and manage in memory caches. we talked about vector databases and our ability to take seven different products today as we continue to expand out across the portfolio.

um we've got zero etl to amazon redshift and we've got dynamo db going to opensearch and we showed a demo where amazon aurora is directly embedded, not only with vss capabilities but directly embedded into bedrock and them working seamlessly together. our ongoing commitment to to, to all of you and to our customers. we want to make sure that we've got the right tool for the job that you can have the system running with operational excellence that you expect that serverless is our new normal. and everywhere we can do serverless where systems scale up and scale down automatically and you don't have to provision number of cpus in memory that that is the new normal. and that's the way we want to make all of our services work.

these services are proven both in terms of performance and to be able to work at at almost any scale. and we are working hard on interoperability across our services and making sure that applications written for these services can work at global scale.

so i just wanted to take a sec, i wanted to really appreciate raul for coming out and kicking us off and talking about our strategy and the two great partners that we were able to share with you today with minas and with gail and we're super proud of what we've got here going and we appreciate all of you being here.

so thank you very much.