# Is there a network call every time we read a row?

*Published on 2026-10-13T00:00:00.000Z*

*By CipherStash Team*

One per operation, and a bulk operation shares a single call. Every key management service needs a network request to supply key material, and ZeroKMS is no exception. The difference is batching. A cloud KMS needs one call per data key. ZeroKMS answers a whole batch in one request, up to the batch size, which is 500 values by default. Encryption and decryption run inside your application process, and plaintext never leaves it.

## Content

On a cloud KMS the answer is yes, once per value. AWS KMS generates one data key per call, and Azure Key Vault and Google Cloud KMS wrap or unwrap one key per call, so encrypting a thousand values under a thousand keys is a thousand calls unless you cache. Caching works. It also means the cached key now protects everything encrypted under it, which is most of what you wanted per-value keys for.

## Where the work happens

The cipher runs in your process, in the SDK's native module. Edge runtimes without native modules use an inline WebAssembly build. Plaintext never crosses the network to us, and the database only sees ciphertext and search terms.

ZeroKMS is a network service, and key derivation needs it. What it returns is seed material, and it batches. A bulk operation obtains what it needs in a single request, up to the batch size of 500 values by default, and derives every value's key locally. Larger operations make one request per batch. Going from ten values to five hundred adds local CPU and does not add requests. Reading a single row is a single request, the same as any KMS.

## What ZeroKMS replaces

The per-value KMS call. ZeroKMS does not sit on top of a cloud KMS in your request path. The authority key inside ZeroKMS is protected under an AWS KMS root key at rest, which is about how we run our service and adds no hop to your operations.

## Numbers

Benchmarks are at [cipherstash/benches](https://github.com/cipherstash/benches) and summarised in the docs. Read them with the conditions attached. The database-side numbers measure EQL on Postgres, and the SDK-to-database round trip is a separate measurement. Run the benchmark on your own hardware before taking a headline number from us.

## Technical evidence

- [Key management concepts: batching](/docs/concepts/key-management)
- [Cryptography reference: where encryption runs](/docs/security/cryptography)
- [Benchmarks](/docs/reference/benchmarks)
- [ZeroKMS compared with AWS KMS](/docs/concepts/compare/aws-kms)

## Related notes

- [Do we have to put a proxy in front of our database?](https://cipherstash.com/notes/do-we-have-to-put-a-proxy-in-front-of-our-database.md) — No. The default is the Stack SDK in your application, on the Postgres connection you already have. Proxy is the alternative for applications you cannot change.
- [Can you see our data?](https://cipherstash.com/notes/can-you-see-our-data.md) — No. A data key needs an authority key held in ZeroKMS and a client key held by you. We have one of them, and plaintext never leaves your process.