PutItem or UpdateItem for a sync?
PutItem when the staged item is complete. UpdateItem with SET when the source sends partial records, otherwise attributes it omitted are erased.
Generador de upsert
Nombra tu tabla, clave y columnas y obtén la sentencia que Amazon DynamoDB acepta de verdad, con una guarda para que una fila antigua nunca sobrescriba una nueva. Debajo: cómo funciona la mecánica, qué se rompe y cómo Datrise carga Amazon DynamoDB de forma incremental.
Las notas técnicas de esta página están en inglés.
Sentencia · PutItem with ConditionExpression
import { DynamoDBDocumentClient, PutCommand } from "@aws-sdk/lib-dynamodb";
// item: { id, name, stage, amount, owner_id, updated_at }
async function upsert(ddb, item) {
try {
await ddb.send(new PutCommand({
TableName: "deals",
Item: item,
ConditionExpression: "attribute_not_exists(#pk) OR #wm < :wm",
ExpressionAttributeNames: { "#pk": "id", "#wm": "updated_at" },
ExpressionAttributeValues: { ":wm": item.updated_at },
}));
} catch (err) {
if (err.name !== "ConditionalCheckFailedException") throw err;
// stale version: a newer item is already stored, skip it
}
}DynamoDB has PutItem, which writes the whole item, and UpdateItem, which edits attributes; neither is an upsert until you add a ConditionExpression. The generated code writes the item only when the key does not exist yet or the stored updated_at is older, and treats ConditionalCheckFailedException as "stale, skip". That gives you a watermark upsert with one request per item.
Batching changes the trade-off. BatchWriteItem takes 25 items but cannot carry a condition, so it is last-write-wins; TransactWriteItems takes 100 conditional writes at twice the cost. Design the partition key from the entity id so writes spread evenly, and keep items small: write capacity is billed per 1 KB, and a nested CRM record with long text lists can cost several units per upsert.
PutItem when the staged item is complete. UpdateItem with SET when the source sends partial records, otherwise attributes it omitted are erased.
No. Batch writes are unconditional. Use TransactWriteItems for conditional batches, or accept last-write-wins and dedupe the batch by key before sending.
Backfills hit many keys at once, which is fine when the partition key is the entity id. Problems come from a low-cardinality key such as account_id; add the entity id to the key or use a sort key.
Datrise aterriza entidades de CRM y SaaS en Amazon DynamoDB con esta misma mecánica, una marca de agua sobre updated-at y columnas tipadas, así que la sentencia de arriba es la que corre por ti. Únete a la lista de espera para acceso anticipado.
Explorar el catálogo de integraciones