SQL语句指定分区键与FeedOptions.PartitionKey是否等价？RU成本有差异吗？

Great question—this is a common point of confusion when scaling Cosmos DB workloads, so let’s break it down clearly:

Equivalence #

These two methods are functionally equivalent in terms of how Cosmos DB processes the query:

• When you add a WHERE c.MyPartitionKey = 'KeyValue' clause to your SQL statement, the query engine parses the condition, recognizes MyPartitionKey as the defined partition key, and routes the query exclusively to that partition.
• When you use the FeedOptions.PartitionKey parameter, you’re directly telling the SDK to target the specified partition. You can even omit the WHERE clause in the SQL statement (though it’s good practice to include it for readability), and Cosmos DB will still only scan the designated partition.

In both cases, the query avoids a cross-partition scan and is restricted to the single target partition.

RU Cost #

Under normal circumstances, there is no meaningful difference in RU consumption between the two methods. RU costs are determined by the work done within the target partition—things like the number of documents scanned, data size returned, and query complexity (e.g., joins, aggregations). Since both methods trigger the same partition-local execution, their RU costs will be nearly identical.

That said, there are a couple of edge cases to note:

• Incorrect conditions: If you mistype the partition key field name in your WHERE clause (e.g., c.MyPartitionKeyy instead of c.MyPartitionKey), Cosmos DB will fall back to a cross-partition scan, which will drastically increase RU usage. Using FeedOptions.PartitionKey eliminates this risk if you ensure the parameter is correctly set.
• Special characters in partition keys: The SDK handles encoding of special partition key values automatically when using FeedOptions.PartitionKey, whereas you’d need to manually escape these in your SQL WHERE clause. Again, this affects correctness more than RU cost, but it’s a practical consideration.

Note on small datasets #

When your dataset is small, cross-partition scans might not show a huge RU difference because there aren’t many partitions to scan. But as your data scales (e.g., millions of documents spread across dozens of partitions), cross-partition scans will become exponentially more expensive. Both of the correct partition key methods will keep RU costs stable because they limit query execution to one partition.

Recommendation #

Choose the method that fits your code style:

• Use the WHERE clause if you prefer self-documenting SQL that explicitly shows the partition filter.
• Use FeedOptions.PartitionKey if you want to centralize partition routing logic in your application code (e.g., for reusable query functions).

Just make sure whichever method you use, you’re correctly targeting the partition key to avoid unintended cross-partition scans.

内容的提问来源于stack exchange，提问作者Aquila Sands