AWS Aurora VS DynamoDB

hello everyone in this video we are going to be doing a comparison between amazon aurora and dynamodb these are two of probably the most popular database solutions that exist on aws today and i think a lot of people really get hung up on the details when trying to decide between one or the other for a new project so what we're going to do in this video is i'm going to do a brief overview of amazon aurora and dynamodb describing what they are what the structure is how they scale and kind of how the technology works from there we're going to move on to an example scenario where we model our application using rds aurora and then in comparison using dynamodb and this will help you really understand how the mental model shifts when you're using one or the other and then finally we're gonna have a section that's dedicated to helping you decide between one or the other so that's what the agenda is for this video so let's jump right into it all right everyone so first of all what i wanted to do is just a brief comparison between rds and aurora because these are two things that belong to the same section of the aws console and a lot of people get very confused in terms of what the difference is between one or the other we're going to be focusing on aurora for most of this presentation but let's just quickly go through what the difference is between these two technologies we have rds and aurora here so let's start with the top by going through what rds is so rds stands for relational database service it's a very old service that was launched in 2009 by aws and essentially it's a managed database solution so what that means in practical terms is that it intends to simplify using databases by handling hardware provisioning setup backups patching storage auto scaling and more so really the intention of rds is to simplify all the nitty gritty all the stuff that you don't really want to have to manually do if you're going to go and set up your own database instance on something like ec2 for example so really it just allows you to spend more time focusing on your business problem as opposed to worrying about operational and maintenance tasks for a database instance so rds itself offers many database engines including mysql postgres sql server oracle and mariadb keep in mind there's different pricing for each of these different types and if you're using something like sql server or oracle you do require licenses that you need to purchase from the specific vendor so i would say like in a nutshell rds is very very similar to running a mysql database on ec2 but a lot of the stuff that you would need to do if you actually set up on ec2 is handled for you so things like deploying to subnets things like security groups things like patching auto scaling incremental version upgrades all of that stuff is made much easier for you so rds is a great choice there is no reason that you should be doing something like my sequel on ec2 and rolling that your own when you have a product like rds that exists out there so that's what rds is let's compare that with amazon aurora so amazon aurora is a database engine that is optimized for the cloud it is an engine that was launched in october of 2014 and it's proven to be a very popular option that provides a lot more value add services when compared with something like rds now keep in mind that aurora is a specific database engine it's its own underlying database implementation so it's not postgresql not mysql not mariadb or anything like that it is its own thing however to make it more attractive as an option to people that are more familiar with using other database technologies it is compatible with both mysql and postgres and this is something that you define when you're creating your instance just a very simple option that you tick do you want to use mysql compatibility or postgres compatibility now what makes aurora extremely special is that it uses an innovative shared storage architecture which decouples storage from compute so in a traditional database setup you'd have a machine and then have a hard disk associated with it and your storage and your compute are the same machine but when working with aurora they allow you to decouple those two things and that allows you to achieve much higher performance throughput now aurora does offer some features on top of those in rds and that includes things like over five times the performance that you would see in a normal mysql database instance keep in mind this is the metric that they publish as kind of a selling point i don't expect everyone to get 5x performance during normal usage so just keep that in mind you may want to kind of experiment with it on your own you get access to more read replicas with a very interesting feature called read replica auto scaling if you're using something like postgres on rds you get access to five read replicas which you need to set up on your own and i don't believe those offer auto scaling in any form now that decoupled storage and compute technology means you have higher availability so behind the scenes aurora is actually replicating your data into different availability zones so that if your primary database goes down at any point in time you're going to have replicas in a sense that are available in other availability zones that can quickly become the primary so very very handy feature it's got higher availability compared to rds and you get automatic backups with no performance impact which is a huge boost and then finally as of a few years ago you also have access to a serverless option which is kind of what lambda did for ec2 that's what aurora is doing for databases so not having to worry about servers is definitely a plus there's a whole kind of laundry list of pros and cons with using the serverless approach but we're not going to really kind of be talking about that too much in this video this is using a more traditional comparison between provisioned rds aurora and dynamodb so that's what rds is that's what aurora is that's kind of the lay of the land in terms of the difference between the two so i just wanted to give you one more slide just to clarify the difference in kind of a simple formula because some people still get confused here i know this took me a little bit of time to really grasp the difference between these two so at the top we have rds here and when you're setting up your rds database you have the option of using all these great engines so mysql postgres sql server maria or oracle and then you also have the option to use aurora now if you select aurora you need to select whether or not you want to use mysql or postgres and then of course they do have a serverless option that works with either postgres compatibility or mysql compatibility so again that's just kind of the difference between these two and just kind of a quick and easy flowchart just to demonstrate this point so that covers what rds aurora is so let's move on now to talk about what dynamodb is so what is dynamodb now dynamodb is a nosql database engine it's an extremely popular database i would say even more popular than something like mongodb these days you see a lot of customers for dynamodb that require very high throughput with consistent performance and that's really what dynamodb provides now it is nosql which means that it's optimized for key value lookups that does mean that it's not intended for things that rds is a little bit better for uh things like aggregations and grouping that's not something that dynamodb is well suited for in fact that's not something you can even do at the database level you'd have to kind of pull your data out of the database and then do grouping on your application layer to achieve a similar functionality so it's definitely a different way of using your data and requires a shift of mental model which we're going to get to in a couple of slides here so in terms of why you would want to use it well it's great for very high performance workloads with very predictable performance in my personal experience i've had applications with over 3000 transactions per second hitting this database with no impact to performance i can't say the same for what that would look like with an rds i haven't tried it personally but just keep in mind like this is the the benefit of using dynamodb it's you get very predictable performance at very high throughputs now on top of all that dynamodb is a fully managed database solution so all you really do is you go into the console you create your database set some limits and you're off to the races it can scale elastically to very large databases think like terabytes of size also supports things like global tables automatic backups auto scaling there's a whole laundry list of different benefits that come with using dynamodb now what's neat about dynamodb is that it operates on a pay for what you use model in fact there are a whole bunch of different kind of pricing models that you can use when you're operating with dynamodb the first one is kind of um it's more meant for bursty workloads so you just kind of say dynamodb i want you to worry about scaling i want you to worry about everything and you just pay for essentially what you use the other options are more of a provision model where you can associate auto scaling rules so as your request rate increases on your dynamodb database it'll automatically scale it up so that it'll be ready to receive all of that traffic and not have anything like throttles or degraded performance so it's definitely flexible depending on how you are using the engine and finally i wanted to also mention that dynamodb now supports transactions so a transaction is kind of a all or nothing all succeed or all fail kind of operation and typically transactions can happen across multiple tables at once this was a very common complaint against dynamodb and why people tended to choose something like rds or something like aurora over a note sql solution like dynamo because it didn't support transactions now it does so there are some limitations that you need to be aware of in terms of how many items you can update at once as part of a transaction but you do have access to those acid principles so atomicity consistency item potency and durability through transactions now there's one additional point here that i wanted to touch on and i didn't really have a point here for it but it's the fact that when you're using dynamodb you also have access to all these great other aws integrations so you can do things like set up dynamodb streams so that on record level updates you can get kind of notifications where you can compare the before and after value that's called dynamodb streams i have a whole video on that there's a whole bunch of other integrations with lambda functions that you can do integrations with api gateway i have a whole bunch of videos on all this stuff but what i'm trying to tell you is that you get a whole lot of value add by using dynamodb because it integrates really well with other aws services that exist in that ecosystem so don't kind of forget that point when you're trying to decide between one or the other there's a whole bunch of value-added features that come with dynamodb now next i wanted to kind of get into more of the details of the differences between them and i like to think of this in terms of four quadrants of database technology so the first quadrant that i want to talk about is structure so how is the database organized or were we talking about graphs are we talking about tables are we talking about documents a lot of different databases use different structures and i want to kind of touch on the difference between aurora and dynamodb the second is in terms of storage so how is data actually stored in the underlying system that's important to understand limitations in terms of scalability and how your application will behave when the size of your data grows to very high levels next i wanted to talk about scale so how does your application actually scale out when it requires both higher throughput and higher storage and finally how do you actually access the thing how do you kind of perform queries do you do it through a database connection do you do it through an api do you do it through a neat ui that kind of shows you all the information in a nice clean and organized way so how do you use it in real life so these are the four areas that i want to talk about so let's first start out with amazon aurora okay so moving to aurora here so we have our four quadrant structure storage scale and access so let's start with structure so in terms of structure there's no really surprises here this is just kind of how you organize data in a traditional sql way so you have tables tables have primary keys they also have foreign keys that you can link to other tables through what are called relationships and let me just kind of highlight that for you here so if we have an accounts table and a country table here if we have a foreign key on country id we can very easily build a relationship between the country table so we can answer questions like what are all the different accounts that are originated in the country of country id 1 which is usa so you can build relationships between your tables here so you can very easily answer those style of questions now you also use schemas and schemas allow you to define things like configurations of your database so what your structures are going to look like also it allows you to define things like constraints on your different column types for so for example if we look at the account id column here it's a variable character or varchar for short we look at creation date it's enforced as a date type and if we look at country id it is an integer type by using aurora you have access to all the tools in your toolkit in the form of tables relationships and schemas very typical of what you would see in just a normal database based on a sql engine now moving on to storage and at first i want to talk about the innovative nature of aurora because it does something a little bit special and it decouples your compute and your storage tier now this is what allows aurora to achieve its very high throughput and a lot of the different benefits that are offered as opposed to kind of partitioning your data or having just copies of an entire database instance on independent machines including storage you have a distributed storage system that exists on its own so traditionally these two things used to be together both the computer and the storage but now these two things are separated in this aurora configuration so there's also some other kind of notes to make here in terms of functionality and it does offer multi-az replication so what that means is that when an item is written to your database it'll asynchronously replicate that to different availability zones so for instance when a right occurs it may go to this top one here um the top one may be in availability zone us east one and the primary may be in us east 1b and then it'll also replicate it to a second availability zone this one could be in us east 1c and the main benefit of this is that if one b or the one in the center here fails for any reason you can very seamlessly with no downtime no interruption fail over to a different node that's in a different availability zone so this is how aurora achieves higher availability when compared with something like rds mysql or rds um using sql server or something like that so it's a great thing if you're looking for more resiliency and more availability for your database engine and because of this kind of distributed storage system you have access to much higher limits in terms of how large your database can be um for roar you have access to 128 terabytes maximum size which is a ginormous size in itself if you're using something like just rds these sizes are dependent on the engine that you use so i believe my sql offers something like 64 terabytes and i think it's different for oracle and mysql server again it's engine specific so you'll have to check into that so that's how storage works with aurora let's move on to talk about scale now so how do we actually achieve higher throughput when we're using aurora so generally there's two ways to scale for hire through but the first way is through vertical scaling and that basically means you just upgrade your machine that's just a click away in the aurora console you just say i want a new compute node and i want it to be i don't know an r6 2xl instance and no failovers no kind of downtime or anything like that you'll get an extra machine that is without configuration now the other way which is probably the more common way to achieve very high levels of throughput is through what is called horizontal scaling and that just implies that you add more machines and split up the work amongst all those different machines so that's kind of the more popular one and let's dig into that a little bit by the way if you're confused about this topic i have a whole other video on horizontal scaling which i'll add in the description section in this video so in terms of how horizontal scaling works specific to aurora you have what's called a master node a master node is responsible for all right events so anytime someone wants to write or add data or modify data or delete data in your database and needs to do so through the master so say for instance you know my database is growing my customers are growing i need more throughput on this application i need to be able to handle more reads so how would i do that well aurora offers read replicas so you can very quickly launch multiple different read replicas so let's say we're going to add reader 1 and reader 2 here now you don't even need to worry about doing this manually you can actually set up auto scaling so that if a database metric gets past a certain point could be something like throughput or i don't know another form of utilization it can automatically scale up the number of reader nodes to up to 15 reader notes so you can alleviate traffic on your master so only dedicate writes to your master node and direct all your read traffic to the reader notes so again that can go up to up to 15 reader notes which is extremely impressive so digging into this a little bit more when you set this up you get assigned a cluster endpoint which points to your master node so all your right traffic should be directed towards there and this is literally like a connection string that you can interact with and then also you get a reader endpoint now if you have a whole bunch of different readers you obviously don't want to keep up to 15 different reader endpoints so aurora offers a very convenient functionality where you get one endpoint for your reader and that is responsible for directing traffic to any of the actual reader nodes so it's kind of like a load balancer that sits between you and your reader nodes so you don't need to worry about like what reader node am i going to communicate with if i want to perform a read operation you just hit that one reader endpoint and it'll distribute traffic to whoever is best suited for that job at the time so really cool stuff by aurora really simplifies a lot of the scaling complexity and management to make your life a whole lot easier for building these really high throughput applications so let's move on to access now so how do we actually talk to the database how do we communicate with it um so the first way is through just a traditional database connection and writing your raw sql this is very popular a lot of people have done this for many many years and if you're comfortable writing raw sql and forming that database connection all the power to you keep on doing what you're doing now for those of you that are like me that are a little bit lazy and don't want to write like low level sql to do what i want you'll probably use something called an object relational mapper sometimes you'll hear that called as an orm for short and essentially what this thing does is that it is a object that you kind of interact with in your programming language to say like perform a query that gets me all the records with this type or does groupings and essentially it's a way for you to access your database in a much more convenient way without worrying about raw sql there's many different orms that are typically tailored to the language that you're using so a very popular one that i've used a lot in java is one that's called hibernate and that just makes your life a whole lot easier now i wanted to touch on a new development in aurora in terms of how people actually access it and work with it and that is what is called the data api and the data api is a new development this just came out pretty recently and i really think this is going to change the way that people interact with databases because it is a great simplification in terms of how to do so so let me explain to you how it is different than the two options above it so the data api allows you to write and submit queries using a rest endpoint so instead of forming a database connection in these above two options all you have to do is write up your sql statement feed it to an sdk which creates a rest request to an endpoint in aurora and aurora will run that sql query against your database internally it's managing that connection pool and doing whatever it needs to do to talk to your instance but from your perspective from the user perspective you are just creating and firing off rest requests and this greatly simplifies using something like aurora because you don't need to form connections you don't need to worry about browning out your database if you have too many clients and too many connections the data api is extremely convenient i already love it i tried it for a new project i'm going to continue using it i really do think that this new way of talking to databases is going to be kind of the de facto uh option of choice going forward so if you're not already familiar with it i highly suggest you go and check it out so this was a brief introduction to aurora talking about structures storage scale and access let's do the same comparison now but for dynamodb so dynamo and let's get those four quadrants up here again perfect so in dynamodb in terms of structure you still have access to things called tables and tables such as collections of items and items are the kind of rows in your database or the entities that exist in your database now you don't have your your traditional primary key in the form of a single column although that is possible but let's just kind of run through here the general format of the structure so this is a table this entire kind of structure here and then these are items so item one two three and four that are in this table now the primary key consists of two items a partition key and the partition key is essentially responsible for segregating your data onto different logical partitions that exist in the dynamodb engine and then you also have the choice of defining a sort key and the sort key allows you to do things like get me all the items within range of in this case within a specific date very very convenient in terms of enhancing your access patterns now if you want to look up independent items on a secondary field by id for example you can create what's called a gsi which stands for global secondary indexes and that allows you to do constant time lookups for example if you're looking for what are all the accounts so these are different accounts that are belonging to the country usa so you would use a gsi to make that a constant time lookup and then over here you just have attributes and the neat thing about dynamodb is that it is effectively schema-less besides the partition key and the sort key in your gsi you can basically dump anything into the attributes so some very complex data objects that have their own fields and types you could just dump that into a raw attribute field for whatever you're using it for so pretty handy pretty useful keep in mind if you're dumping json data in here keep in mind that you're not going to be able to index it using a gsi effectively so one of the limitations there to be aware of now in terms of storage how does storage work in a dynamodb engine well it all relies on something that's called the hashing function and a hashing function is basically a function that's written by dynamo that helps dynamo decide which partition your data is going to be located on so let's run through a very quick example here so it all starts with your function f of x in this case where x is the input that you're going to provide your database so let's say we want to add item one to our database instance you'll pass item one and it's payload maybe it has a couple attributes into dynamodb dynamodb will take item one and it'll hash that into a unique value and that value will effectively point to a particular partition that exists within dynamodb now this partition can be its own independent database that exists in isolation of other partitions so the output of the hashing function is the location or what partition this record will be located on so the output in this case was partition one and now item one exists on partition one and so let's do this for a second example say we have item two the same operation is performed f x and maybe the output of this hashing function is partition two and again this can be its own independent instance on whatever storage engine they're using behind the scenes but it exists in independence of partition one partition one and partition two have no idea that each other exists and just running through the example here we decide that it goes on partition two and now item two and its payload exist on partition 2. so now dynamodb knows exactly where these items with these particular keys are located so let's do the reverse now and assume that you're looking for an item let's say we're looking for item number one dynamodb will hash item one see what the output is and that output will point to partition one and that's where item is located so dynamodb will know exactly which partition that item is located on and where that item is on that partition so that's how it achieves some very impressive look up speed that is consistent uh especially as your data grows so that's kind of how data is stored within dynamodb let's talk about scale now and how it achieves some very awesome essentially infinite scale so in terms of scaling there's a very simple formula here and it's it's not that complicated so the the way that dynamodb scales is either adding more or splitting partitions so in the above example we only had two partitions but there's nothing stopping you from having this hashing function have a whole bunch of different partitions partition one partition two partition three partition a hundred essentially your data can just keep on horizontally scaling and since each of these partitions are operating independently of one another and don't know anything about each other you can just keep on adding more and even breaking apart partitions if your data on that partition gets too high or your request rate gets too high so that's kind of how dynamodb achieves its quote infinite scale unquote uh just by adding or splitting partitions up so moving on to access now access is pretty straightforward for dynamo you use the aws sdk depending on what language you're using i know the popular one for python is both core there's one for all you node.js developers as well but there's very different language specific kind of flavors that essentially offer the same functionality at the end of the day if you're not happy with using that there are some language specific orms or object relational mappers that exist out there i use java a lot the one that i'm very familiar with is dynamodb mapper which is an excellent way to abstract some of the complexity when trying to talk to dynamodb it gives you kind of a an interface to perform a lot of the very typical operations such as queries scans and pagination things like that alright so we covered uh structure storage scale and access for dynamodb now now let's kind of wire this back to the comparison between uh rds aurora and dynamodb because it does require a very different mental model a very different way of approaching the problem and i think this is where a lot of people get lost when they try to compare one or the other because it requires a very different perspective and i figured the best way to describe this is through just an example let's just give a very practical example using either rds aurora compared with dynamodb so let's start with rds aurora and the mental model that you use when you're using aurora and basically any other sql database is that you start with your data relationships so you say to yourself you know what is the problem set that i'm working with what are the relationships between our data let's define a schema that respects that relationship and then you would go and build out your tables that kind of respect that schema and then you would after the fact start accessing your data in a way which is compliant with those relationships that you defined now dynamodb is very much so different you don't start with your data relationships you start with something different you start with your access patterns so you ask yourself not how is my data structured but how do i want to access my data how do i actually want to retrieve it is it by specific keys is it by specific you know ranges between dates what are you trying to do how are you trying to access your data so as you can imagine these are very different mental models when you are comparing these two things and you need to structure your data in a way that is fitting for each of these two different solutions so let's take a practical example using a customers and orders example we have a set of customers that place orders maybe on an online marketplace or something so let's start at the top with aurora so i have orders that come in and this is a very kind of typical orders table where you have your primary key being your order id you have your customer id which is a foreign key which points to another table which is your customers table and then you also have date there which corresponds to when the order was placed so because you're working with a sql engine here you would probably define your foreign key to link up to the primary key of your customers table so then you can very easily answer questions like what are all the orders for customer id one which happens to correspond to john doe so this is a very traditional way of setting up your rds aurora you would define these relationships and now how you access your data is dependent on those relationships you define and the schema that you define now how does this work how would we solve this exact same problem with dynamodb so you would start with a very different process you would start with a statement such as i want to be able to access my data by block and whatever blah is that would influence how your dynamodb table structure exists so let's take a practical example let's say that i want to be able to access all order ids for a customer by their customer id okay so i want to be given a customer id that is going to be provided to me and i want to know all order ids that are associated with it and all the details about that customer as well so how can we do that in dynamodb so let's take a look at this table here which is one that i quickly put together that works for this access pattern that we've defined ourselves so what we do here is we have our customer id and this is our partition key and then we also have a sort key and sometimes also called the range key that exists and that's going to be our order id so what you can see here is the combination between these two things 1 seven one and nine nine eight two and nine nine nine these are unique combinations so as a as a conjunction these two things formulate our primary key and then from there we have customer details that correspond to kind of what we had over here for our customer table instead now we are just storing some raw json to denote the customer details of our independent customers now if you're glancing at this a very obvious question is hey daniel what's going on here you are repeating your customer details uh for more than one row here that that's not good you have data duplication and you would be exactly right and this is part of the pros and cons balancing act between using rds and dynamodb you are able to achieve very high throughputs for this particular access pattern that we've defined but the penalty that you have to pay to play this game is that you suffers from some form of data duplication now this isn't necessarily a terrible thing right like dynamodb is extremely efficient it can store a whole ton of data very simply so is this really a problem i would argue not because you're being cognizant of the limitations here right you are saying to yourself i am willing to suffer some form of duplication in favor of better throughput and better performance overall so that's the price of the ticket and what you pay in exchange for that performance upgrade now you may ask yourself well doesn't this cause problems like what if you know the the customer details change for john doe what if he wants to change his address at some point after he places an order and you would be exactly right again part of the consequences of using dynamodb in this case is that now if a customer places an order and they want to change their address you need to do something like take a look at this table find all the order ids for this customer that are still open and then go and modify all of the addresses that are corresponding to open orders for that customer whereas if we just had a customers table up here in an orders table here we would just change the address for john doe and then you know you'd be off to the races everything just just works so all the open orders will be mapped to the new address um so this is an example like a very practical example of how you would model your data using something like rds aurora compared with something like dynamodb so hopefully this gave you a sense of what what kind of problems you'll be dealing with if you're working with one over the other one final point here is don't try to design a dynamodb table as you would a rds table it's just not going to work and this is the trap that people fall into and they end up giving up and say oh i hate dynamodb let's go back to rds you need to think about how you want to access your data can't stress that enough a lot of the time that you need to spend is up front to understand hey how do i want to actually access this how will my potential use cases evolve so that in the future i can very easily just add an index to something so that you know if there's a new use case i can access that data easily that's something you need to think of ahead of time when you're working with dynamodb whereas when you're using something like aurora it's more of like this is my data now go and access it so that kind of gives you an outline of what the difference between these two technologies look like let's move on now to talk about like when to use what how do you actually decide from a practical perspective so first i want to work on the left side here which is amazon aurora so you want to use amazon aurora when you want to keep the door open for flexible access patterns so as we saw in that previous example you define your schema you define your structure based on your data and you define those relationships between your data this makes it very easy to pivot in the future if you know someone comes along and says you know i want to select my data in this way it's very very easy to do that if someone comes along and wants to add another table for a new relationship very very easy to do that when it comes to dynamo not so easy to do that so if you have a use case where maybe you're just prototyping something or maybe or you're not really sure how your application is going to evolve you want to use something like aurora that's flexible in nature that's going to be able to allow you to query by all sorts of different access patterns secondly when you want to perform bulky relational style queries things like grouping things like aggregations things like very sophisticated filtering this is a better choice for aurora in fact dynamo b does not even offer any form of grouping or aggregations or group by clauses or anything like that if you want to do that in dynamodb you need to pull all the data out by value or by key rather and then do some kind of grouping on the application tier whereas when you're using something like aurora you can offload a lot of that complexity to the database instance so that you have a lighter load on your application layer so aurora is great for performing these types of queries and assess and especially with the addition of read replicas you can always add more read replicas to help you deal with the demand of you know these large style grouping and aggregation style queries they're usually more computationally expensive now thirdly when you want to enforce schema constraints this is something that i think a lot of people gloss over but when you're using an rds and aura in particular you are able to define schema constraints that enforce at the database level that certain fields and certain columns are always of a specific type and look the same in dynamo that is not the case you do not have a fixed schema you have a flexible schema uh so that's something to be very very aware of if that's something that you care about then you know you're going to want to use aurora um and if it's something you don't care about then dynamodb is good for you and finally from the kind of support perspective when you want to use a ubiquitous access language such as sql sql is everywhere everyone knows sql if you don't know sql you probably should because at some point in your life you're going to need to run some kind of queries against the database and there's a whole bunch of support that exists for sql queries and performing different groupings and all that kind of stuff so that's the the extra value add that you get by using aurora by having a whole ton of support that exists out in the wild that will be able to support you with any questions in terms of sql itself so shifting gears now to dynamodb when do you want to use that well when you have predictable access patterns when you know in advance i'm going to access my data in this particular way or these these particular sets of ways and you want to achieve high performance on that when you know in advance it's a good idea to use dynamo and when you're convinced that that's probably not going to change definitely a good idea to use dynamo because you're going to be able to scale a lot further if you use something like aurora and secondly when your search key is known in advance this is something that some people don't think about actually so when you're using dynamo there's no such queries that you can do such as give me all the rows with a creation date between these two two ranges these two dates you can't do that with dynamo you need to know the key that you are looking for in advance so instead you would have to do things like give me all the values that have this key and are within this particular date range this may not work for some of you for some of your different use cases so keep that in mind that's a limitation and when you're using dynamo you need to know what key you are looking for whereas when you're using something like aurora you can do that fuzzy logic that fuzzy search criteria that is like give me all the stuff with this elaborate list of criteria dynamo is much more rigid in this sense you need to provide it with your keys in advance and thirdly when you are willing to sacrifice flexibility for ultra fast and consistent performance this is really the the big selling point at the end of the day uh consistent performance that's ultra fast is what you get with dynamodb provided you don't do something crazy or faux pas from the table design perspective but when you're using dynamo you kind of limit yourself to a particular fixed set of access patterns which you typically define in advance however you can basically rest assured that your application is going to to scale essentially infinitely so that's the kind of trade-off that you get between one or the other you get excellent speed consistent performance and essentially infinite scale at the cost of flexibility so that's all i got for you today if you enjoyed this video i have a whole bunch more on aurora and dynamodb i'll put playlists up on the pop-ups here and as always if you enjoyed the video please don't forget to like and subscribe and i'll see you next time

Channel: Be A Better Dev

Views: 8,169

Rating: 5 out of 5

Keywords: aws, aws simplified, awssimplified, programming, coding, cloud computing, software design, software engineer, software developer, software architecture, beabetterdev, be a better dev, be a better developer, system design, databases, aws cloud, aws tutorial, aws training, aws aurora, aws rds, aws aurora vs dynamodb, aurora vs dynamodb, dynamodb vs aurora, dynamodb vs rds, what is rds, what is aurora, what is dynamodb, aws dynamodb vs aurora

Id: crHwekf0gTA

Length: 38min 38sec (2318 seconds)

Published: Mon Apr 26 2021