Rust headless API for WordPress content, indexed fast.
HyperIndex is an optional fifth container per Yovale site that indexes posts, products, taxonomies and ACF fields into a sub-millisecond REST API. We're building it now — waitlist is open.
in development · 2GB+ plans · we'll email when preview opens
Headless API on the same VPS as your site.
HyperIndex runs in its own container next to your WordPress site. Same dashboard, same backups, same network. This is a mock of the preview surface — numbers are targets.
- 12:04:22API clientGET /posts?slug=hello · 0.7ms200
- 12:04:18GPTBotGET /products · 1.1ms200
- 12:03:55API clientGET /products/123 · 0.9ms200
- 12:03:42Reindex jobpost#4567 updated · 1.8s lagok
- 12:03:11API clientGET /search?q=docker · 2.4ms200
WP-JSON is convenient. It is not fast.
The WordPress REST API runs through PHP-FPM on every request. It carries the cost of WP bootstrap, plugin hook chains and database round trips on a synchronous request path. Most sites can serve a homepage faster than they can serve /wp-json/wp/v2/posts.
If you want a fast headless surface today you bolt on WP GraphQL, WPGraphQL Smart Cache, or you copy content into Algolia / Typesense / Meilisearch — three vendors, three sync paths, three places things can drift out of date.
HyperIndex puts a Rust process next to your WordPress site that reads the same database, indexes content into an in-process store, and serves REST queries under a millisecond. One container, same VPS, same backups, no third vendor.
Sub-millisecond reads, same-VPS writes.
Four design decisions locked in. None of this ships today — these are the constraints HyperIndex commits to before preview.
- 0101runtime
Rust core, embedded index
Compiled-language process running in its own container with bounded memory and CPU. No PHP bootstrap on the query path, no per-request hook chain to wade through.
design locked - 0202data
Reads the WP database directly
Tails the WordPress database for changes — posts, postmeta, terms, ACF fields, WooCommerce products — and keeps an in-process index up to date with <2s lag.
<2s index lag - 0303api
REST first, GraphQL later
Clean REST surface — /posts, /pages, /products, /taxonomies, /search — modelled on WP-JSON shapes so existing clients port with minimal rework. GraphQL is on the roadmap behind launch.
REST at launch - 0404packaging
Plan-gated by RAM
HyperIndex needs memory. We don't ship it on 1GB plans (Starter). Growth plans (2GB+) include 128MB allocation; Business (4GB+) gets 256MB. Available, not forced.
Growth+ only
How HyperIndex compares to today's options.
WP-JSON / WPGraphQL / Algolia
HyperIndex (target)
stack direction · still being built
One new container per site, opt-in.
Each Yovale site currently runs 3-4 containers (WordPress, MariaDB, optional Redis, optional staging). HyperIndex would be the fifth, attached only on plans with the memory to spare. The dashboard, agent and backup paths reuse what we already ship.
A long-running Rust process per site. Bounded memory (128MB or 256MB depending on plan), bounded CPU share. Indexes WordPress content as it changes.
Reads WordPress changes from MariaDB's binary log, applies them to the index. No webhook plugin required, no cron drift, no third-party sync vendor.
API requests route through the same Traefik edge that serves the WordPress site, on a subdomain. Auto SSL, HMAC-signed admin endpoints, same observability dashboard.
Bundled into Growth and Business, no add-on tier.
If HyperIndex ships at the target performance, it'll be included on Growth ($249/year, 5 sites, 128MB index per site) and Business ($499/year, 15 sites, 256MB per site). Starter ($149) doesn't have memory headroom for it. Numbers may shift before launch.
Growth $249/yr · Business $499/yr. Starter excluded — needs 2GB+ RAM per site. Pricing direction, not commitment.
See what's shipping today.
Things this builds on.
Things developers ask before joining a waitlist.
When does this actually ship?+
Private preview target is Q4 2026, public launch after that. We're building Yovale Pages first because it's a larger demand surface; HyperIndex follows on the same infrastructure investments.
Why Rust and not Go or Node?+
Memory predictability and tail-latency consistency. A 128MB index needs to behave the same after 30 days as after 30 minutes. Rust gets us there without a GC tuning ritual.
Will it work with my custom ACF fields and custom post types?+
Yes. The index reads schema-on-read from the WordPress database, including ACF tables, custom post types and registered taxonomies. No content type is hard-coded.
What about WooCommerce?+
First-class. Products, variations, prices, inventory and order-related queries are indexed alongside posts and pages. HyperIndex was sketched on the assumption that 'WordPress content' includes Woo.
Can I run it on my own VPS via bring-your-own-server?+
That's the goal. The BYO line will get HyperIndex via the same plan-gating logic — sized to whatever your VPS actually has.
What if it's slower than this in practice?+
If we can't ship sub-millisecond p95 on warm cache for typical queries, we won't ship it as a product. Honest performance targets, no shipping a slow thing under a fast name.
Join the waitlist before preview opens.
We're opening preview in waves to Growth and Business customers first. Waitlist subscribers get the launch performance numbers verified publicly before paying — no marketing-only benchmarks.