Smarter Query Engine

Complex pages need data from multiple places. A customer detail page might need the customer's record, their recent orders, their open invoices, their assigned contacts, and a computed metric about their total lifetime value. That's five data fetches — at minimum.

Without query optimization, each of those fetches hits the database independently. Some might request overlapping data. Some might be redundant because the same data is needed by two different components on the page.

The smarter query engine eliminates this waste automatically.

Deduplication by Detection

The query engine tracks what data has been fetched within a request. When a second component asks for data that was already fetched as part of the first component's request, the engine serves the result from the in-request cache rather than making a second database call.

This happens without any component-level configuration. Components don't need to know about each other or coordinate their data fetching. The engine handles the deduplication transparently.

Batching Related Queries

When multiple components need the same type of data — say, three separate components on a page all need related records from the same object type but with different filter conditions — the engine batches these into a single optimized query where possible.

One query with multiple conditions is generally faster than three separate queries, and it's significantly less expensive in connection and parsing overhead.

Request-Level Scope

The cache is scoped to the current request. It doesn't persist between requests, so there's no risk of stale data from a previous page load affecting the current page. Each request starts fresh and builds its cache as it processes the components on the page.

This is an important distinction from application-level caching, which requires careful invalidation logic to avoid serving stale data. Request-level caching is safe by design.

Measurable Impact

The impact of query deduplication compounds with page complexity. A simple page with one or two components sees modest improvement. A complex page — a dashboard with many metrics cards, related records panels, and data tables — sees significant improvement because the redundancy problem grows with component count.

Pages that previously generated 40+ database queries for a single load now generate 8-12. The reduction in database load is visible in page performance and in database resource utilization across the platform.

Invisible to Users, Visible in Speed

Users don't see the query engine — they see pages that load quickly. The optimization is infrastructure, not a user-visible feature. It makes everything faster without requiring anything from the people using the platform.

That's the ideal kind of performance work: invisible in mechanism, obvious in effect.