# Data Partitioning ## Vertical Partitioning We can partition our database in such a way that we store tables related to one particular feature on one server. Issues of this approach: * We'll still have scale issues when one table contains trillions of records that can't fit in one server. * Joining two tables in two separate databases can cause performance and consistency issues. ## Range based partitioning We can store files in separate partitions based on the first letter of the file path, i.e. we save all the files starting with letter 'A' in one partition and those that start with letter 'B' into another partition and so on. We can even combin certain less frequently occurring letters into one databse partition. Issues of this approach: * Lead to unbalanced servers. ## Hash based partitioning We take a hash of the object we are storing and based on this hash we figure out the DB partition to which this object should go. For example, we can use the hash of the fileID to determine the partition the file will be stored. This approach can still lead to overladed partitions which can be solved by using Consistent Hashing. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://liuzhenglaichn.gitbook.io/system-design/database/data-partitioning.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.