The Short Answer
Compute pushdown means running the filter, the scan, or the distance computation on the machine that already holds the bytes, instead of shipping those bytes across the network to a query engine that will throw most of them away. If a query touches a 4 GB segment and returns 40 rows, moving 4 GB to compute the answer is the expensive part. The arithmetic was never the problem.
For search over object storage the practical version is: push metadata predicates and candidate generation down to the storage node, and pull back only the surviving candidates. A filter that eliminates 99% of a segment should eliminate 99% of the bytes you transfer, not 0%. Whether you can do that depends entirely on whether anything is running next to your data, which is why pushdown is an architecture decision rather than a query optimization.
The thing that decides it is boring: object storage APIs return whole objects.
GET gives you the object, or a byte range of it if you know the offset. Neither one evaluates a predicate. So pushdown over object storage requires either a storage service that speaks a richer protocol, or a compute layer you place next to the storage yourself.What Does Compute Pushdown Actually Mean?
The term comes from query engines. A planner that receives
SELECT title FROM docs WHERE year = 2026 has a choice: read every row and filter in the engine, or hand the year = 2026 predicate to the storage layer and read only matching rows. Handing it down is pushdown. Databases have done this internally for decades; the interesting recent shift is pushing past the process boundary, into the storage system itself.Three things commonly get pushed:
WHERE clauses at the storage layer. Parquet stores per-row-group min/max statistics precisely so a reader can skip a row group without decoding it.COUNT, SUM, or a top-k at the source and return the result rather than the inputs.DuckDB's write-up on querying Parquet is the clearest worked example of the first two: the same query against the same file can read a few megabytes or the whole thing depending on whether the reader uses the statistics.
Why Is The Network The Bottleneck And Not The Math?
A dot product over a 768-dimensional float32 vector is roughly 768 multiply-adds. A modern core does billions of those per second. Transferring that same vector over a network is about 3 KB, and at realistic object-storage throughput the transfer costs more wall-clock than the arithmetic by orders of magnitude.
Scale it to a shard holding ten million vectors and the asymmetry becomes the whole story. The compute to score them is seconds of CPU. The transfer is roughly 30 GB. Any architecture that moves the vectors to the compute is paying the expensive cost to avoid the cheap one.
This is why the useful mental model is not "where is the CPU" but "how many bytes cross the wire". Pushdown is a byte-reduction technique that happens to be expressed as a placement decision.
What Can And Cannot Be Pushed Down?
| Operation | Pushable | Why |
Metadata predicate (brand = "acme") | Yes | Evaluated against a payload index at the storage node; cuts candidates before any vector is read |
| Projection (return 3 fields, not 40) | Yes | Columnar layout makes partial reads contiguous |
| ANN candidate generation | Yes | The index structure lives with the segment; traversal is local |
| Distance computation | Yes | Vectors never leave the node; only scores and ids come back |
| Per-shard top-k | Yes | Each shard returns k, the coordinator merges |
| Global top-k across shards | No | Requires results from every shard; the merge is inherently central |
| Cross-collection joins | Partly | Only if both sides are colocated, which is rarely true |
| Reranking with a cross-encoder | No | Needs a model the storage node does not host, and operates on the merged candidate set |
How Have Other Systems Solved This?
S3 Select is the direct attempt: S3 Select lets you run SQL against an object and return only matching records, with a documented SQL subset. It works on CSV, JSON and Parquet, and the subset is narrow enough that it fits filter-and-project workloads rather than anything resembling vector search.
Aurora pushed the redo log down into a purpose-built storage tier so the database stops shipping full pages. The VLDB paper on Aurora's storage layer is the canonical writeup, and its central claim generalizes well beyond relational workloads: the network is the constraint, so move the smallest possible representation.
Arrow and Parquet solved the format half. The Arrow columnar specification makes it possible to read a column without decoding a row, which is the precondition for projection pushdown being cheap rather than merely possible.
What none of them give you directly is vector search. An ANN index is not a SQL predicate, so a storage service that speaks SQL cannot traverse an HNSW graph or an IVF posting list on your behalf.
Do I Actually Need Pushdown?
Three questions, in order:
1. What is your selectivity? If a typical query's filter eliminates a small fraction of the corpus, pushdown saves little, because you were going to read most of it anyway. If the filter is highly selective, the savings are close to the elimination rate. 2. Where does your latency go? Instrument the split between transfer and compute. If compute dominates, pushdown is the wrong lever and you want a better index or budget-aware retrieval. 3. How often do you re-read the same bytes? A hot working set that fits in cache makes the transfer cost disappear on repeat queries, and storage tiering is the cheaper fix. Pushdown earns its complexity on cold, wide, selective scans.
If all three point the same way, the follow-on question is whether you control the storage layer at all. Pushdown is not something you can add to a system whose storage is an API you call.
What This Means For Search Over Your Own Object Storage
Running retrieval over content in your own bucket is exactly the case where this bites. The data is in S3-compatible object storage, the index derived from it is large, and the naive architecture fetches segments to a query service on every cold query.
Mixpeek's vector store is built on the other side of that decision. Its shards are a service that owns the segment format, the payload index, and the ANN structure together, so a filter on
metadata.brand and the vector traversal both execute where the bytes are, and the coordinator receives per-shard candidates rather than segments. Owning the storage layer end to end is the precondition, not a detail. That is the same reason hybrid BM25 and vector fusion can run per shard: the inverted index sits beside the vectors instead of in a separate system.The primitives this maps onto are the bucket holding your objects and the collection holding what was extracted from them. MVS is the standalone path if you already have embeddings, and pricing is per stored vector and per query rather than per byte scanned, which is the billing shape pushdown makes possible.
Frequently Asked Questions
Is compute pushdown the same as edge computing?
No. Edge computing moves compute closer to the user to cut round-trip latency. Compute pushdown moves compute closer to the data to cut bytes transferred. They can point in opposite directions: the storage node holding your index may be nowhere near your users.
Does S3 Select work for vector search?
Not usefully. It evaluates a SQL subset over CSV, JSON and Parquet, which covers metadata filtering but has no notion of an ANN index. You can use it to narrow candidates by scalar predicates, then you still have to fetch vectors and score them somewhere.
Can I add pushdown to an existing vector database?
Only if it already colocates compute with segments. If your vector store is a service you query over the network and it fetches from object storage internally, pushdown is its architectural decision to make, not yours. What you can control is selectivity: better metadata indexes reduce the candidate set regardless of where the work runs.
How much does pushdown actually save?
It scales with selectivity, so there is no single number worth quoting. The useful way to estimate it is to measure the ratio of bytes read to bytes returned for a representative query. That ratio is roughly the upper bound on what pushdown can remove, and the real saving is lower because index structures and headers still have to be read.
Does pushdown make queries cheaper or just faster?
Both, in different currencies. Faster because less data crosses the network. Cheaper because object-storage pricing charges for requests and egress, and because the compute doing the scanning is smaller. The tradeoff is that storage nodes now need CPU and memory they did not need as a pure blob store.
What is the main risk of relying on pushdown?
Skew. Pushdown makes each shard do more work, so an unevenly distributed filter can leave one shard scanning while the others idle, and the query is as slow as the slowest shard. Adaptive indexing and careful partitioning are the mitigations.