Timestream (Live Analytics) Write Float Precision vs Pricing

Question

this page gives an example of write pricing:
https://docs.aws.amazon.com/timestream/latest/developerguide/metering-and-pricing.writes.html

---

| Time                | region     | az | vpc           | Hostname    | measure_name     | measure_value::double |
|---------------------|------------|----|---------------|-------------|------------------|-----------------------|
| 1602983435238563000 | us-east-1  | 1d | vpc-1a2b3c4d  | host-24Gju  | cpu_utilization  | 35.0                  |

- time = 8 bytes  
- first dimension = 15 bytes (`region` + `us-east-1`)  
- second dimension = 4 bytes (`az` + `1d`)  
- third dimension = 15 bytes (`vpc` + `vpc-1a2b3c4d`)  
- fourth dimension = 18 bytes (`hostname` + `host-24Gju`)  
- name of the measure = 15 bytes (`cpu_utilization`)  
- value of the measure = 8 bytes

**Write size of the time series event = 83 bytes**

---

i have a question about preserving the precision for `"DOUBLE"` type numbers related to the cost of the writes:
the write clients all want a stringified value. so if i want to save the precision of almost all 64 bits (maybe except the last bit rounding due to stringify), i would need a very long string. for example, π = "3.141592653589793115997963468544185161590576171875". this string is about 50 characters long.

does this count towards the write cost as that is what i need to put into the client, or the value of the measure would still be counted as 8 bytes?

re:Post Agent · Accepted Answer

When writing double precision floating-point numbers to Amazon Timestream for LiveAnalytics, the cost is based on the actual storage size of the data type, not the string representation you provide to the write client.

For DOUBLE data types, Timestream uses 8 bytes of storage, regardless of the precision or length of the string representation you provide. This means that even if you send a very long string representation of a number (like your example of π with 50 characters), Timestream will store it internally as an 8-byte double-precision floating-point number.

In your example calculation of write size, the value of the measure is correctly listed as 8 bytes, which is the standard size for a double-precision floating-point number. This 8-byte size is what will be used for pricing calculations, not the length of the string you use to represent the number when writing to Timestream.

It's important to note that while you can provide high-precision string representations of numbers, the actual precision stored will be limited to that of a standard double-precision floating-point number (typically 15-17 significant decimal digits). Any additional precision beyond this will be lost when the number is stored in Timestream.

So, to answer your question directly: the write cost is based on the 8-byte storage size of the DOUBLE type, not the length of the string representation you provide to the write client. You can safely use high-precision string representations without incurring additional write costs, but keep in mind that the stored precision will be limited to that of a standard double-precision float.  
**Sources**  
[Metering and cost optimization - Amazon Timestream](https://docs.aws.amazon.com/timestream/latest/developerguide/metering-and-pricing.html)  
[Amazon Timestream Pricing – Time-Series Database – AWS](https://aws.amazon.com/timestream/pricing/)  
[Accessing Amazon Timestream for LiveAnalytics using the AWS CLI - Amazon Timestream](https://docs.aws.amazon.com/timestream/latest/developerguide/Tools.CLI.html)

Timestream (Live Analytics) Write Float Precision vs Pricing

Add your answer

Relevant content