---
title: "Float Bloat: vector serialization gone wrong"
author: "Matt Gross"
date: 2026-08-27
canonical_url: https://bonsai.io/blog/float-bloat/
license: CC BY-SA 4.0
license_url: https://creativecommons.org/licenses/by-sa/4.0/
copyright: Bonsai.io, 2026
---

Bonsai has discovered a pervasive issue with vector search across the entire ecosystem, impacting millions of implementations, and present in official vendor SDKs, documentation, tutorials, and articles.

Most embedding models return vectors as float32, but many clients cast and serialize them as float64. That doubles the precision, which doubles the disk and network cost. The extra digits add no accuracy, so you're paying to store and move noise.

We call this problem "Float Bloat"

one embedding valuewhat your encoder prints

0.8433808.

+0wasted bytes per 768-dim vector. These are digits that encode nothing your float32 didn’t already hold

**We estimate this problem globally at over 20 Petabytes of unnecessary disk storage overhead.**

What does the problem look like? Suppose you get a vector from your favorite model, embeddings API, or inference provider. It will return a list of float32s as the vector:

```json
[ -0.011625106, 0.014652754, 0.0172214, -0.0177951529, 0.027116421, 0.06390719, 0.0082179, ... ]
```

But when the client casts and serializes the embedding, it raises the values' precision to float64 and adds meaningless digits to every dimension:

```json
[ -0.011625106446444988, 0.014652754180133343, 0.017221400514245033, -0.017795152962207794, 0.02711642161011696, 0.063907191157341, 0.008217900060117245, ... ]
```

The added precision is just a side effect of floating point conversion (known as widening). It is not more accurate, and the additional digits take up disk space and network bandwidth. Depending on the vector database and search algorithm used, this can also result in additional CPU overhead when calculating vector similarity.

## How often does it happen?

At Bonsai, we sampled 18 diverse vector search clusters across all tiers, and found that 12 out of those 18 contained float bloat. All the way from sandbox through enterprise.

We also found it in the main branch of the world's most popular embedding vendor SDK, and in the public documentation of the world's largest cloud companies. It's present in hundreds of blogs and tutorials, and in numerous open source repos.

# How does it happen?

Nobody does this on purpose. It's the default behavior in several popular languages used for vector search. Take this Python example. You have an embedding stored in an object and you need to serialize it, either for transfer or storage:

```python
# Python with NumPy
embedding = my_numpy_vec.tolist() #<-- this is the culprit
json.dumps(embedding)
```

The above will provide float64 widened from float32.

In Python, The fix is cryptic and must be done explicitly, which explains the high prevalence of the problem:

```python
# Python with NumPy
values = my_numpy_vec.tolist()
embedding = [float(f"{value:.9g}") for value in values]
json.dumps(embedding)
```

Unless care is taken, the problem surfaces often during binary to JSON conversions, conversion to base64 and back, and when the incorrect numeric type is used in the client.

## A float32 has nine digits and a float64 has seventeen.

A `float32` has a 24-bit mantissa and at most **9 significant digits**. Cast it to `float64` and the value is unchanged, but it now lives on a far finer grid that needs up to **17 digits**. The default serializer will then cast and print all 17.

The serializer usually gets the blame, but the extra digits come from the cast. Most encoders will print a genuine `float32` correctly; the value just tends to get promoted to `float64` before it ever reaches them.

| Real dtype | Mantissa bits | Round-trip digits | Format |
| --- | --- | --- | --- |
| bfloat16 | 8 | 4 | %.4g |
| float16 | 11 | 5 | %.5g |
| float32 | 24 | 9 | %.9g |
| float64 | 53 | 17 | shortest |

## Estimating impact

We serialized the same 768-dim vector across five languages. Widened JSON runs **~1.8×** the shortest-float32 text and **~5×** the raw float32 binary. This is about 8 wasted bytes per value, and it repeats on every stored copy and every network hop. A re-index, replica, snapshot, and client cache are four copies and four hops, each carrying the widened precision.

| Corpus (768-dim) | Widened JSON | Shortest text | float32 binary | Text fix saves | Binary saves |
| --- | --- | --- | --- | --- | --- |
| 1M vectors | 15.2 GB | 8.6 GB | 3.1 GB | 6.6 GB | 12.1 GB |
| 10M vectors | 151.8 GB | 86.0 GB | 30.7 GB | 65.8 GB | 121.1 GB |

Use this handy calculator to estimate how much of your overhead is waste.

Vectors stored10M

Dimensions / vector768

384768102415363072

Copies & hops5×

Widened JSON, all copies

—

—

Recovered by %.9g (lossless text fix)

—

~43% smaller, same values, fewer digits

Recovered by going binary

—

~80% smaller: base64 / Arrow / pgvector, exact

Rough annual bill on the wasted text

—

commodity object storage + one cross-region ship / yr · order-of-magnitude

## Find and Fix It

In the languages with no `float32` scalar (**JavaScript, Python, Ruby**), widening is forced the instant a value leaves the typed array, so the fix is to format the digits yourself. In the ones that keep a real float (**Java, C#, Rust**), the fix is simpler: delete the up-cast and let the native encoder see the `float32`. Every fix below is lossless.

JavaScriptno float32 scalar

◤ where it bloats

```
JSON.stringify([...f32arr])
// a Float32Array element
// reads back as float64
```

◦ corrected

```
'[' + Array.from(f32arr,
  x => x.toPrecision(9)
).join(',') + ']'
```

Pythonno float32 scalar

◤ where it bloats

```
json.dumps(vec.tolist())
// .tolist() promotes f32
// to a Python float (double)
```

◦ corrected

```
'[' + ','.join(
  '%.9g' % x for x in vec
) + ']'
```

Rubyno float32 scalar

◤ where it bloats

```
JSON.generate(vectors)
// Ruby Float is always
// 64-bit; no f32 exists
```

◦ corrected

```
'[' + vectors.map { |x|
  '%.9g' % x
}.join(',') + ']'
```

Javaopts into double

◤ where it bloats

```
temp.add((double) v[y][j]);
// double[] → Jackson
// prints 17-digit doubles
```

◦ corrected

```
float[] embedding = v[y];
// Jackson emits
// shortest-float32
```

C#opts into double

◤ where it bloats

```
double[] Embedding { get; }
Serialize(embedding);
// store truncates to f32 anyway
```

◦ corrected

```
float[] Embedding { get; }
Serialize(embedding);
// or ReadOnlyMemory<float>
```

Rustresists by default

◤ where it bloats

```
json!(vec_f32)
// serde's json! macro
// widens during serialize

```

◦ corrected

```
to_string(&vec_f32)
// serde (ryu) emits
// shortest-float32
```

We've also released a new agent skill `bonsai-fix-float-bloat`, available in the Claude Marketplace as part of `omc/search-skills` that can find and fix this issue for you. See it in our [Search Skills](https://github.com/omc/search-skills) repository on Github.

## It's almost never your embedding service

We surveyed OpenAI, Voyage, Cohere, Jina, Google, AWS, and Huggingface inference endpoints on `float32` models. Every native wire we could sample emits shortest-float32 decimals. If your stored vectors are seventeen digits long, look at your client because that's probably the problem.

#### Where it actually enters

SDK `.tolist()` calls, OpenAI-compatible wrapper shims, framework serializers, and “save embeddings to JSON” tutorials. OpenAI’s own SDK even requests compact base64 float32 bytes, then throws the win away with `.tolist()`.

#### The cure already shipped

Cohere, Voyage, and Jina expose `int8`, `binary`, and `base64` output types. A 1024-d binary vector is **128 bytes** versus ~11 KB of widened JSON. Most tutorials ignore them and hand-roll `json.dumps` instead.

## The fix, in order of preference

The bug needs two things on the storage path: a promotion to `float64`, _and_ writing it as decimal text. Break either link and the bloat is gone.

1.  **Serialize at the real precision.** `%.9g` (Python/C), f32 `ryu` (Rust), `strconv.AppendFloat(b, x, 'g', -1, 32)` (Go), `toPrecision(9)` (JS).
2.  **Don't leave binary in the first place.** If both ends are yours, ship base64 float32 bytes, Arrow, npy, or protobuf `repeated float`.
3.  **Pass through without re-serializing.** If you're only relaying already-correct text, stream the bytes; don't parse-then-re-encode.

Also, talk to us at Bonsai if you're interested in seeing how we can help scale up your hybrid and vector search needs.

_Copyright ©️ Bonsai.io, 2026 · By Matt Gross · Originally published at https://bonsai.io/blog/float-bloat/ · CC BY-SA 4.0_