Another consideration for your data in RDS instances is sharding. When the data access pattern allows it and the distribution of the data is relatively uniform across the database, sharding can be a way of storing data that can almost linearly increase the write performance of our databases. With sharding, we can distribute the data to several RDS backend clusters; for example, if we have a phone directory and we are storing names from A-Z, these names are more or less evenly distributed. We can introduce sharding and distribute the names from A-M in the first shard on one cluster and the names from N-Z to the second shard residing on the second cluster.

Sharding is a good way of increasing the performance of our database clusters when the data is evenly distributed, but it does have some inherent drawbacks, such as the complexity of performing data projections, table joins, and other complex SQL transactions for which we usually employ ACID-compliant relational databases. For example, a BI report might need to source and compare data from several databases and compile the appropriate relationships on the BI server instead of in the database, if the BI server even supports this kind of approach.