Purpose Built AWS Databases
Data is an integral part of any application and performance of the application depends a lot upon the data store used to save it for processing. Initially lot of apps were using relational databases but the needs of the applications is now changing. A well architected application with variation in data model is the need of the hour. One size fit all database no longer works in this era.
This does not mean relational database do not fit in current era. They are still in use and still power lot of apps. Like any other aspect of our applications, database are also designed to solve a particular problem and are built for a purpose. In my opinion it is very important to understand and match the purpose with the use case and the problem you are trying to solve. This will help you to write scalable and high performant applications.
Welcome to the Era of Purpose Built Database
In this new world, everyone wants to built a huge scale internet applications. These application requires a diverse set of data models and have diverse set of tech stack requirement too. We have started using micro-services, micro-frontends to solve the diverse tech stack requirement but what about data. We are still using the same old generic database solution and trying to make it fit for the purpose it is not designed for. The diverse set of data models is the need of the hour to built those high performant applications we are working on. There are many types of databases available today and each of these solve a purpose. Following is the list:-
- Relational: Enables you to define database schema as well as relational constraints on the schema.
- Key-Value: Enable you to have fast read/write. They are highly partitioned and can scale quickly.
- Graph: Relations are first class citizen in graph databases. You can have properties on relations and can do traversal queries over relation. Data is modelled and navigated as a graph.
- Document: De-normalised data stored in JSON documents. This model maps to the tendency of humans modelling the data in their mind. They have flexible schema and expressive query.
- In-Memory: This type is good for low latency and high scale operations per second. Good for storing data for something like cache.
- Time-Series: Provides performing storage for the data that accumulates over time. Time is the primary axis and this type is good for performing time based data modelling.
- Ledger: Immutable and cryptographically verifiable data store. It only allows you to append the data in the store and keeps the ledger as name suggest for all the actions that have taken place in the past
- Search: Many applications output a lot of logs or needs a functionality to perform a search in tons of data. These data stores comes up with advance search capabilities to provide support in this scenario.
We have talked about the various database types based on the purpose. Following is the list of the offerings by AWS for purpose built databases:-
|Database type||AWS service||Use Case|
|Relational||Amazon Aurora, Amazon RDS, Amazon Redshift||Traditional applications, ERP, CRM where referential integrity is important|
|Key-Value||Amazon DynamoDB||High traffic web apps|
|Graph||Amazon Neptune||Fraud detection, social network, knowledge graphs, recommendation engine|
|Document||Amazon DocumentDB (with MongoDB compatibility)||content management, user profiles|
|In-Memory||Amazon ElastiCache for Memcached and Redis||caching, session management|
|Time-Series||Amazon Timestream||IoT applications, time series data like stock tickers|
|Ledger||Amazon QLDB||record systems, financial transactions etc.|
|Search||Amazon Elasticsearch||full-text search and advanced analytics|
AWS provides the above mentioned options to build modern applications and support various types of data models required in building those applcations. Like we are not building monolithic applications any more and we are migrating towards micr-services, we should also start looking into the need for purpose built databases.I would love to hear what you think about this article and if there anything you would like me to cover in future. Drop me a line on @awsmag.