Why Query is the primary read operation in DynamoDB - Performance Analysis

Time Complexity: Why Query is the primary read operation

O(n)

Understanding Time Complexity

When working with DynamoDB, it is important to understand how the main read operation, Query, performs as data grows.

We want to know how the time it takes to get data changes when we ask for more items.

Scenario Under Consideration

Analyze the time complexity of the following DynamoDB Query operation.

const params = {
  TableName: "Users",
  KeyConditionExpression: "UserId = :id",
  ExpressionAttributeValues: {
    ":id": { S: "123" }
  }
};

const result = await dynamodb.query(params).promise();

This code fetches all items with a specific UserId from the Users table using Query.

Identify Repeating Operations

• Primary operation: Reading items matching the partition key in the index.
• How many times: Once per item returned that matches the query condition.

How Execution Grows With Input

As you ask for more items with the same key, the work grows roughly in direct proportion.

Input Size (n)	Approx. Operations
10	About 10 item reads
100	About 100 item reads
1000	About 1000 item reads

Pattern observation: The time grows linearly with the number of items returned.

Final Time Complexity

Time Complexity: O(n)

This means the time to get data grows directly with how many items you ask for.

Common Mistake

[X] Wrong: "Query always scans the entire table, so it is slow like Scan."

[OK] Correct: Query uses the partition key to jump directly to matching items, so it only reads relevant data, making it much faster than Scan.

Interview Connect

Understanding why Query is efficient helps you explain how to design fast data access in DynamoDB, a key skill for real projects.

Self-Check

"What if we changed the Query to a Scan operation? How would the time complexity change?"