Alle Items aus DynamoDB in Node.js holen (AWS SDK v3)

Eine ganze Tabelle in SDK v3 zu lesen heißt, einen Scan bis zum Ende zu paginieren. Jede Antwort ist bei 1 MB gedeckelt, und du gibst LastEvaluatedKey als ExclusiveStartKey zurück, bis keiner mehr kommt (wie DynamoDB-Cursor funktionieren).

Die Schleife unten ist von Hand geschrieben, damit der Cursor sichtbar ist. In echtem Code würdest du zu paginateScan greifen, das das SDK bereits mitliefert.

Code

import {DynamoDBClient, ScanCommand} from '@aws-sdk/client-dynamodb';

const client = new DynamoDBClient({region: 'us-east-1'});

const items = [];
let lastEvaluatedKey;

do {
  const response = await client.send(
    new ScanCommand({
      TableName: 'Music',
      ExclusiveStartKey: lastEvaluatedKey
    })
  );

  items.push(...(response.Items ?? []));
  lastEvaluatedKey = response.LastEvaluatedKey;
} while (lastEvaluatedKey);

console.log(`Table holds ${items.length} items`);

Erklärung

paginateScan macht genau das schon — import {paginateScan} from '@aws-sdk/client-dynamodb', dann for await (const page of paginateScan({client}, {TableName: 'Music'})). Es wird aus denselben drei Cursor-Feldern generiert, die die Schleife oben von Hand nutzt (ExclusiveStartKey, LastEvaluatedKey, Limit) — am Verhalten ändert sich beim Wechsel also nichts.
Nur ein fehlender LastEvaluatedKey bedeutet fertig — eine Antwort mit null Items und einem Cursor ist normal, keine leere Tabelle. Bei Items.length === 0 abzubrechen ist der klassische Fehlende-Zeilen-Bug, und eine FilterExpression macht leere Seiten zur Routine statt zur Seltenheit.
Limit zählt ausgewertete Items pro Aufruf, nicht Items insgesamt — es ist das dritte Feld, das der Paginator steuert, und weder es noch der pageSize des Paginators begrenzt die Größe des Arrays, das du am Ende hältst.
ExclusiveStartKey: undefined im ersten Durchlauf ist in Ordnung — der Serializer verwirft undefined-Member, die erste Iteration braucht also keinen Sonderfall.
items wächst auf die Größe der Tabelle — verarbeite jede Seite innerhalb der Schleife und lass sie los (schreiben, streamen, aggregieren), es sei denn, du weißt, dass die Tabelle klein ist. Anzusammeln ist einen Tabellenzuwachs von einem Out-of-Memory-Crash entfernt.
Ein Scan rechnet jedes gelesene Byte ab, bei jedem Lauf — ProjectionExpression verkleinert, was über die Leitung geht, nicht die Rechnung (warum), und eine FilterExpression verwirft Items, nachdem sie gelesen und berechnet wurden (Scan mit Filter). Auf einem heißen Pfad willst du eine Query.
Teil ihn mit Segment / TotalSegments auf — N asynchrone Worker, jeder mit eigenem Cursor über seinen eigenen Abschnitt, alle auf einem gemeinsamen Client. Node führt sie bereitwillig nebenläufig aus; die Lesekosten ändern sich nicht, nur die Wanduhr (wann sich das lohnt).

Mach es visuell

Der DynamoDB Query Builder generiert dieses gesamte Programm samt Pagination-Schleife aus einem Formular, in SDK v3 und sieben weiteren Zielen.

DynoTable blättert eine Live-Tabelle für dich in einem unendlich scrollenden Grid durch und exportiert den Scan hinter diesem Grid als lauffähigen Code. DynoTable herunterladen.

Referenzen

Scan — Amazon DynamoDB API Reference
Scanning tables in DynamoDB — Amazon DynamoDB Developer Guide
DynamoDB read and write operations (capacity unit consumption) — Amazon DynamoDB Developer Guide
[paginateScan — AWS SDK for JavaScript v3 source](https://github.com/aws/aws-sdk-js-v3/blob/main/the client-dynamodb ScanPaginator module)

Zuletzt verifiziert am 2026-07-28 gegen die oben verlinkte offizielle AWS-Dokumentation.

Alle Items aus DynamoDB in Node.js holen (AWS SDK v3)

Code

Erklärung

Mach es visuell

Verwandte Beispiele

Referenzen

Diesen Request visuell bauen