About hev layer
Layer was built to extend modern search offerings, by providing an opinionated set of abstractions.
It’s helpful to get familiar with these concepts before reading the detailed documentation.
Kubernetes Control Flow
A control loop is Layer's core primitive for managing an index. It reconciles the index's state against metrics coming back from the search system — which is how row-level transforms get applied and how a namespace's stable view stays current. You set the target; the loop notices the drift and closes it.
Karpenter GPU Autoscaling
Because Layer is stateless, every tier scales independently. Karpenter handles nodes, KEDA scales pods against signals from an embedded PostgreSQL queue. That queue carries scaling signal only — no non-recoverable state — so a tier can drop to zero and come back with nothing to restore.
tpuf Wire Compatibility
Layer speaks the turbopuffer wire. Existing clients point at the gateway and keep working — same calls, same shapes, no rewrite. That compatibility is also what makes the store behind it a choice rather than a commitment: applications use the gateway API while the configured store handles storage and retrieval.
Envelope Decoration
The gateway extends your search system with query patterns and filtering primitives it doesn't ship. Enhancements ride on reserved _hevlayer_* attributes and degrade gracefully if the schema changes underneath them. It stays one API surface — Python, Go, TypeScript, or plain REST — so applications can route every call through Layer, including the ones needing nothing extra.
Scatter/Gather Index Sharding
Layer can partition a namespace into hash buckets — shards — by stamping each row with a reserved attribute. A query then scatters to every bucket in parallel and gathers the results, merging and re-ranking down to the top_k you asked for. Sharding stays invisible: you issue one query and get one ranked list back.
NVMe Document Cache
The cache does two jobs from one store, and it is built on NVMe rather than RAM — Aerospike keeps its index in memory and the records themselves on local flash, so the cache holds far more than a memory-sized working set. Document reads are pull-through: check the cache, read through to origin on a miss, backfill best-effort. Pipeline chunk handoff uses the same store as the queue between CPU and GPU workers. Neither job is a hard dependency — reads fall through to origin, chunks fall back to S3.
What’s in the Box
Layer doesn’t reinvent the runtime. It composes proven open source and owns the seams between the pieces — so what you operate is a stack your team can already reason about, and every part of it is one you could have chosen yourself.
Karpenter handles node provisioning alongside these.
-
Kubernetes the runtime, and the CRDs you declare against
-
KEDA pod scaling, and scale-to-zero
-
Aerospike the NVMe-backed document cache
-
PostgreSQL pipeline and indexing state
-
VictoriaMetrics the embedded PromQL series
-
Terraform the cluster and its cloud footprint
-
Helm installing and upgrading Layer itself
-
Amazon S3 snapshots, history, clickstream
-
Cloudflare R2 coming soon
-
Google Cloud Storage coming soon
-
Nodes appear for the burst and drain after it
Karpenter provisions capacity against pending pods and takes it away when the work stops, so a GPU pool costs nothing between runs.
-
Pods scale from real queue depth, down to zero
KEDA reads the embedded PostgreSQL queue directly rather than guessing from CPU, so a tier with no work waiting runs no replicas at all.
-
Handle concurrent reads and writes
An NVMe cache built on Aerospike simplifies your pipeline implementation, and makes document chunks available while your index catches up.
-
Pipeline state survives every restart
PostgreSQL holds the pipeline state machine and indexing state, scoped deliberately narrow so nothing unrecoverable lives outside your store.
-
Metrics you can query without standing up a scraper
An embedded VictoriaMetrics keeps a PromQL-compatible time series the gateway proxies for you, so the dashboard and your own queries read the same data.
-
Snapshots, history and clickstream stay durable
S3-compatible object storage holds namespace snapshots, search history and clickstream events — portable, and readable without Layer in the path.