Replication makes copies. Partitioning splits the data, and that split is the hardest thing in your system to change. Pick the wrong key and the bill arrives as a rewrite rather than a slow query.
By range. A–F here, G–M there. Range scans stay cheap. But new users all arrive with the same few letters, and one shard takes every write.
By hash. Spread evenly, no hot spots. But "everything from last Tuesday" now has to ask every shard.
The real question is neither of those. It is what a single query has to touch.
Good partitioning co-locates what the query needs — a customer's orders, invoices and history on the same shard, so one query hits one node. Bad partitioning scatters what belongs together, and then every read becomes a fan-out and every cross-shard write needs a distributed transaction you would rather not have.
Choose the key that keeps things read together, stored together.
Some decisions are cheap to revisit. Know which ones aren't before you make them casually.