Metode ini menggunakan rumus matematika (fungsi hash) pada kunci shard untuk menetapkan data. Misalnya, sistem dapat menghitung ID Pengguna (mod 4) untuk menetapkan pengguna ke 1 dari 4 server.

Meskipun membantu mendistribusikan data secara konsisten, fungsi hash hanya memastikan distribusi yang merata jika kunci shard memiliki kardinalitas tinggi dan kemiringan frekuensi rendah. Jika Anda memilih kunci shard dengan nilai umum, seperti "Nama Belakang" yang "Smith"-nya muncul 1.000 kali lebih banyak daripada "Pyne", fungsi hash akan mengirim setiap kumpulan data "Smith" ke shard yang sama. Hal ini akan membuat "hot shard" meskipun menggunakan rumus matematika.

Menambahkan server baru juga sulit dilakukan dengan metode ini karena formulanya berubah, yang sering kali mengharuskan Anda untuk "melakukan sharding ulang" atau memindahkan data Anda ke cluster server baru.

Data ditetapkan berdasarkan rentang nilai. Misalnya, Anda dapat menempatkan ID Pengguna 1–1.000 di Server A dan 1.001–2.000 di Server B. Hal ini sangat intuitif dan bagus untuk kueri yang perlu membaca urutan data (kueri rentang). Kelemahannya adalah "hot spot"—jika semua pengguna baru Anda ditetapkan ke Server B, server tersebut akan melakukan semua pekerjaan sementara Server A tidak digunakan.

Strategi ini menggunakan tabel pemeta (direktori) yang melacak dengan tepat shard mana yang menyimpan data apa. Strategi tersebut menawarkan fleksibilitas terbesar karena Anda dapat memindahkan data antar-shard tanpa mengubah formula. Namun, tabel pemeta ini menjadi bottleneck; setiap kueri harus memeriksa direktori terlebih dahulu, sehingga menambah latensi. Jika direktori gagal, seluruh database menjadi tidak dapat diakses.

Geo sharding menetapkan data ke server tertentu berdasarkan lokasi fisik pengguna. Misalnya, data untuk pengguna di Prancis disimpan di server di Uni Eropa, sedangkan pengguna AS disimpan di server di Amerika Utara. Hal ini secara signifikan mengurangi latensi (kecepatan) bagi pengguna dan membantu perusahaan mematuhi hukum residensi data seperti GDPR.

Terkadang disebut partisi fungsional, hal ini melibatkan pemisahan data berdasarkan fitur, bukan berdasarkan baris. Misalnya, Anda dapat menempatkan semua tabel "Profil Pengguna" di Server A dan semua tabel "Upload Foto" di Server B. Meskipun data diatur secara logis, secara fungsional, arsitektur ini mirip dengan arsitektur data microservice dan tidak menyelesaikan masalah jika satu fitur tertentu (seperti Foto) tumbuh terlalu besar untuk satu server.

Sharding adalah jenis partisi horizontal tertentu yang mendistribusikan potongan data ke server yang sama sekali berbeda. Hal ini mengatasi batas kapasitas hardware (penyimpanan) dan bottleneck throughput tulis, karena server yang berbeda dapat memproses penulisan secara bersamaan.

• Sharding manual: Dalam lingkungan sharding manual, developer atau administrator database bertanggung jawab untuk menentukan kunci shard, membuat infrastruktur untuk setiap shard, dan menulis logika untuk merutekan kueri. Hal ini memberi Anda kontrol terperinci atas lokasi penyimpanan data. Namun, hal ini memerlukan pemeliharaan yang signifikan. Jika satu shard menjadi terlalu besar, Anda harus "melakukan sharding ulang" data secara manual, yang melibatkan pemindahan jutaan baris ke server baru sambil mencoba meminimalkan waktu non-operasional aplikasi.
• Sharding otomatis: Sharding otomatis, yang sering ditemukan di database NoSQL seperti Bigtable atau database SQL terdistribusi seperti Spanner, menangani distribusi data dan traffic secara otomatis. Sistem memantau ukuran data dan beban di setiap server. Jika shard tertentu menjadi "hot spot" atau tumbuh terlalu besar, mesin database akan otomatis membagi shard dan memindahkan data ke server yang tidak terlalu padat. Hal ini mengurangi beban operasional pada tim Anda dan membantu memastikan performa yang konsisten seiring dengan penskalaan aplikasi Anda.

Partisi melibatkan pembagian tabel besar menjadi bagian-bagian yang lebih kecil dan mudah dikelola (seperti membagi tabel log per bulan) tetapi tetap berada di instance server yang sama. Hal ini menyelesaikan masalah penyimpanan dengan mempermudah pengarsipan atau penghapusan data lama tanpa memengaruhi tabel lainnya. Namun, hal ini tidak menyelesaikan masalah server. Karena semua partisi masih berada di satu mesin, partisi tersebut terus berbagi CPU dan RAM yang sama, yang berarti partisi tidak dapat membantu jika server mencapai batas performanya.

Replikasi adalah proses penyalinan seluruh database ke beberapa server. Opsi ini dapat menjadi pilihan yang baik untuk ketersediaan baca; jika satu server gagal, server lain dapat mengambil alih. Namun, hal ini tidak membantu penskalaan tulis karena setiap bagian data yang ditulis harus disalin ke setiap replika, sehingga membatasi kecepatan tulis ke kapasitas satu mesin.

Yang tak kalah penting, sebagian besar model replikasi hanya mengizinkan satu "penulis" (node utama) dalam satu waktu. Jika Anda mencoba mengizinkan beberapa server menerima penulisan secara bersamaan, Anda berisiko mengalami konflik penulisan, yang mana dua server mencoba mengupdate kumpulan data yang sama dengan informasi yang berbeda. Menyelesaikan konflik ini secara teknis sulit dan dapat menyebabkan kehilangan data atau inkonsistensi jika tidak ditangani oleh sistem terdistribusi yang canggih.

Database terdistribusi, seperti Spanner, memberikan manfaat sharding tanpa overhead manual. Sistem ini dirancang untuk ditempatkan di seluruh cluster mesin sejak awal. Sistem tersebut secara otomatis menangani distribusi, penyeimbangan ulang, dan replikasi data secara transparan. Beberapa sistem ini memiliki beberapa penulis dan secara otomatis menangani konflik penulisan. Hal ini memungkinkan Anda melakukan penskalaan secara horizontal sekaligus mempertahankan konsistensi database relasional tradisional.