Kepler searches 100M+ financial documents with turbopuffer

turbopuffer is how we search the long tail of our corpus without spending an outrageous amount.

Sara Kromwijk, Founding Engineer

Kepler is building deterministic AI infrastructure for finance. Unlike most vertical AI software, Kepler's AI combines inference, retrieval, and code to produce reproducible and defensible outputs. When a financial analyst asks about the revenue growth of a public company, Kepler's response traces to an exact line item in that company's latest SEC filing.

Kepler uses turbopuffer to search millions of SEC filings, earnings transcripts, and investor relations (IR) presentations across 14k+ public companies and 27 global markets, alongside each customer's private documents.

Why turbopuffer?

Kepler's value proposition is "AI that proves it's right". A deterministic code layer can trace every number to source, but only if that source surfaces in search. To keep the "always right" promise, Kepler needs to index every financial document that might surface an answer.

The disk-based search engines that Kepler evaluated would have forced them to carefully plan node capacity to balance utilization and performance as the corpus grew. Every new document would carry the potential cost of an added node.

turbopuffer builds indexes directly on object storage, so each new document is just another object on S3, with a predictably low marginal cost.

Active namespaces get pulled into a local NVMe SSD / memory cache, so hot queries are just as fast as disk-based systems. turbopuffer's object-storage-native query engine minimizes round trips to object storage even on cold queries directly to S3, so Kepler's tail latencies are bounded (940ms p99, 1.2s max) such that parallelized search tool calls are never slower than inference in Kepler's pipeline.

turbopuffer namespaces create data isolation boundaries that Kepler can enforce at varied permission levels. SEC filings are indexed in a single shared namespace containing 100M+ public documents. Private documents are indexed in user-level namespaces that might contain only a few dozen documents. Namespaces carry no billing overhead, can be added without limit, and can each hold 100M+ documents without sharding. Cost grows only with storage and query volume, not namespaces or node count.

turbopuffer namespaces are the perfect data isolation primitive. The API and pricing are consistent whether a namespace has 10 documents or 10 million.

Michelle Van, Engineer

turbopuffer in Kepler

Kepler indexes every document in turbopuffer for vector and full-text search. Public documents like SEC filings are kept in single large namespaces accessible by every client, and private documents like SharePoint are kept in namespaces scoped to the organization or user. Kepler upserts embedded document chunks into turbopuffer namespaces alongside full text and metadata attributes like document type, title, year, and creator.

When a user asks a question, an orchestrator agent interprets the query and spawns sub-agents for various tasks. A search sub-agent uses turbopuffer hybrid vector + full-text search and combines the results with reciprocal rank fusion. Results then pass through an external reranking model that selects the top 20 by relevance.

A verifier sub-agent may also retrieve chunks related to those returned to assess the validity of a chunk within its context. Kepler's deterministic code layer then extracts numbers from each document and generates reports and spreadsheets, in which each stated fact cites a verified source.

Results

Kepler searches terabytes of public and private financial documents at 10x lower cost than capacity-based alternatives.

• 100M+ documents
• 85ms p90 latency
• 940ms p99 latency
• 1.2s max latency

What's next

• Security primitives: As Kepler pursues more security-conscious customers, they plan to deploy separate turbopuffer BYOC clusters in the customers' VPCs, and use namespace-level customer-managed encryption keys so that end customers can control encryption.
• Scaling large public namespaces: As Kepler scales up, public corpora like SEC filings will begin serving higher query volumes across all users. Kepler plans to use namespace pinning to ensure predictable query performance and pricing on large shared namespaces.
• Expand into other verticals: Kepler's infrastructure is domain-agnostic by design, and they plan to extend the same architecture that verifies financial data to other industries.

We will continue to update this log as Kepler's turbopuffer usage evolves.