Low level put_item changing number format into DynamoDB. Is this a bug?

[NatxoM]

I have this data to entry into AWS DynamoDB:

item = {
    "PK": {
        "S": "DEBUG"
    },
    "SK": {
        "S": "#ID_LOG#2025-10-09T07:48:31.105674+00:00"
    },
    "data": {
        "M": {
            "t": {
                "N": "1.00000000000000007629769841092E+50"
            }
        }
    },
    "ttl": {
        "N": "1759999711"
    }
}

I use this code to put it into the table:

db_client = boto3.client('dynamodb')
response = db_client.put_item(
    TableName = "mytable",
    Item = item
)

But the data inserted in the table is:

{
 "PK": {
  "S": "DEBUG"
 },
 "SK": {
  "S": "#ID_LOG#2025-10-09T07:48:31.105674+00:00"
 },
 "data": {
  "M": {
   "t": {
    "N": "100000000000000007629769841092000000000000000000000"
   }
  }
 },
 "ttl": {
  "N": "1759999711"
 }
}

Why? Is this a bug?

[github-actions[bot]]

Hello! Reopening this discussion to make it searchable.

[tayfuryldz]

This is not Boto3 changing the value. DynamoDB Numbers are numeric values, not strings with a preserved textual representation.

In the low-level API, {"N": "..."} uses a string in the wire shape so decimal numbers can be transmitted without JSON floating-point loss. DynamoDB parses that string as a Number. Scientific notation and the expanded decimal integer in your example are numerically equivalent:

1.00000000000000007629769841092E+50
= 100000000000000007629769841092000000000000000000000

So after storage, DynamoDB is free to return/display a canonical decimal representation rather than the exact spelling you supplied. The low-level client does not make the "N" field a string attribute.

If preserving the lexical form (including E+50, trailing zeroes, etc.) matters to your application, store it as {"S": "1.000...E+50"} instead. If numeric comparisons/arithmetic/index ordering matter, keep it as N and compare it as a number rather than comparing the serialized spelling.

One additional constraint is worth checking for generated values: DynamoDB supports up to 38 digits of precision. Your example has 30 significant digits, so it is within that limit. Values with more precision can fail rather than round-trip arbitrarily.

You can verify the distinction without the console by doing GetItem with the low-level client: the returned attribute remains type N, but its string payload may be normalized. That is representation normalization, not a change in the numeric value.