SingleStore's sharded architecture is composed of aggregator and leaf nodes, with the aggregator node taking on roles similar to both the query router and config servers in MongoDB. Data distribution across partitions uses a hash function on the shard key, resulting in rows with the same shard key residing on the same partition. Unlike MongoDB, SingleStore does not have a balancer job that moves chunks or rebalances shards, instead relying on hashing to determine data distribution. To optimize performance on sharded tables, consider using sort keys, reference tables, projections, and rowstore tables. When choosing a shard key, ensure even distribution of data across leaf nodes, shard tables frequently joined on those columns, and select keys that minimize cross-partition communication for high-concurrency workloads. However, some best practices may conflict with each other, and updating the shard key after creating a table is not possible in SingleStore.