Query Rewriting and Optimization: Business Use Case for HeliosDB-Lite

Document ID: 48_QUERY_REWRITING_OPTIMIZATION.md Version: 1.0 Created: 2025-12-15 Category: Performance & Optimization HeliosDB-Lite Version: 2.5.0+

Executive Summary

Poorly optimized queries cause 70-90% of database performance issues, yet developers lack the expertise or time to hand-optimize every query in fast-moving product development. Traditional databases apply basic query optimization at execution time but cannot rewrite queries to fundamentally better patterns, leaving performance on the table. HeliosDB-Lite’s HeliosProxy Query Rewriting Engine provides an intelligent middleware layer that intercepts SQL queries, applies 50+ optimization rules (subquery flattening, predicate pushdown, join reordering, materialized view substitution), caches optimized execution plans, and learns from query patterns to continuously improve performance—all transparently without application code changes. Organizations deploying HeliosDB-Lite’s query rewriting achieve 5-50x speedup on analytical queries, 80-95% reduction in expensive full table scans, elimination of N+1 query patterns through automatic batching, and developer productivity gains by eliminating manual query tuning. For analytics platforms, business intelligence tools, ORM-heavy applications, and data-intensive microservices, HeliosDB-Lite’s query rewriting transforms database performance from a constant engineering bottleneck into an automatic, self-improving system.

Problem Being Solved

Core Problem Statement

Modern application developers write SQL through ORMs, query builders, and code generation tools that produce syntactically correct but semantically inefficient queries, leading to 10-1000x performance degradation versus hand-optimized SQL. Database query optimizers can choose efficient execution plans for well-written queries but cannot fundamentally restructure poorly written queries (e.g., converting correlated subqueries to joins, eliminating redundant predicates, recognizing materialized view opportunities), forcing organizations to employ expensive database specialists for manual query tuning or suffer degraded application performance that drives user churn.

Root Cause Analysis

Factor	Impact on Operations	Current Workaround	Limitation of Workaround
ORM-Generated Inefficient Queries	ORMs (ActiveRecord, Hibernate, SQLAlchemy) generate N+1 queries, correlated subqueries, excessive JOINs; developers focus on app logic, not SQL optimization	Manual query tuning via raw SQL for critical paths; eager loading configuration	Requires deep ORM knowledge, breaks abstraction layer, high maintenance burden
Lack of Query Optimization Expertise	90% of developers don’t understand EXPLAIN plans, join algorithms, or index usage; performance problems discovered in production under load	Hire database specialists ($150K-250K/year) to review and optimize queries	Doesn’t scale; specialists become bottleneck; can’t review every query in fast-moving development
Static Query Optimization Limits	Database query optimizers choose execution plans based on statistics but can’t rewrite fundamentally bad query structure (e.g., SELECT * to SELECT specific columns)	Add database hints, rewrite queries manually, create materialized views	Requires per-query manual work; hints break on database version upgrades; materialized views need maintenance
No Learning from Query Patterns	Same bad query pattern repeated across codebase (e.g., filtering after join instead of before); no system learns “this pattern is always slow”	Code review processes to catch bad patterns; linting tools for SQL	Human review doesn’t scale; linters can’t understand semantic inefficiency, only syntax issues
Execution Plan Cache Misses	Queries with different parameter values treated as distinct queries, re-planning overhead adds 5-50ms latency	Use prepared statements; manually normalize queries	Requires application code changes; doesn’t help for ad-hoc queries from BI tools

Business Impact Quantification

Metric	Without Query Rewriting	With HeliosDB-Lite	Improvement
Analytical Query Latency	5-60 seconds (complex reports, dashboards)	0.5-5 seconds (rewritten + optimized)	10-50x faster
Full Table Scan Frequency	40-60% of queries (due to poor predicates)	5-10% (after predicate pushdown, index selection)	80-95% reduction
Database Specialist Time	40-60 hours/week manual query tuning	5-10 hours/week (monitoring only)	75-85% reduction = $100K-180K annual savings
Developer Productivity Loss	20-30% time debugging slow queries, optimizing ORMs	2-5% (rare exceptions)	8-15x productivity improvement on DB work
User Churn from Slow Reports	5-15% users abandon slow dashboards (> 10s load)	< 2% (sub-5s dashboards)	60-85% churn reduction

Who Suffers Most

Business Intelligence & Analytics Teams: Building dashboards, reports, and ad-hoc queries using tools like Tableau, Looker, Metabase that generate inefficient SQL with excessive JOINs, unfiltered subqueries, and missing indexes. They spend 40-60% of time waiting for slow queries or manually optimizing SQL, preventing them from delivering insights to stakeholders on time.
SaaS Application Developers Using ORMs: Writing Ruby on Rails, Django, or Laravel applications where ActiveRecord/Eloquent ORM generates N+1 queries, eager loading misconfigurations, and correlated subqueries. They lack SQL expertise to optimize queries, rely on caching to mask performance problems, and face production incidents when cache fails or new features bypass cache layer.
Data Engineering Teams: Running ETL pipelines and batch jobs that process millions of rows with complex transformations (window functions, recursive CTEs, multi-table joins). They manually rewrite queries to optimize for performance, spending 30-50% of time tuning instead of building new data pipelines, and struggle to maintain optimized queries as data schemas evolve.

Why Competitors Cannot Solve This

Technical Barriers

Competitor Type	Core Limitation	Why It Persists	Business Consequence
Traditional RDBMS (PostgreSQL, MySQL)	Query optimizer chooses execution plans but cannot rewrite query structure; limited to algebraic transformations like join reordering	Optimizer runs inside query executor; no middleware layer to intercept and rewrite queries before execution	Developers must write well-structured queries manually; bad queries stay bad
Cloud Data Warehouses (Snowflake, BigQuery)	Optimized for columnar storage and distributed execution; minimal query rewriting beyond standard optimizations	Focus on infrastructure scaling, not query intelligence; assume well-written SQL from data analysts	Still require SQL expertise; ad-hoc queries from BI tools remain slow
ORM Frameworks	Can add eager loading hints and query batching, but limited to ORM-specific patterns; no cross-ORM learning	ORMs are client-side libraries; no visibility into database execution or ability to rewrite SQL after generation	Each ORM has different optimization strategies; developers must learn ORM-specific tricks
Query Monitoring Tools (DataDog, New Relic)	Identify slow queries through APM but provide no automatic fixes; require manual investigation and optimization	Monitoring is observability-only; no control plane to modify queries	Shows you the problem but doesn’t solve it; still need DBA time to fix

Architecture Requirements

Transparent Proxy Layer with Full SQL Parsing: Requires a middleware component (HeliosProxy) positioned between application and database that can intercept every SQL query, parse it into an abstract syntax tree (AST), understand semantic intent (not just syntax), and rewrite the AST before passing to the database engine. This cannot be added to traditional databases without breaking the client/server protocol or requiring application changes.
Optimization Rule Engine with Cost Estimation: Demands a library of 50+ optimization rules (subquery flattening, join elimination, predicate pushdown, materialized view substitution) with cost-based analysis to determine whether applying a rule improves performance. Must integrate with database statistics (table sizes, index cardinality, data distribution) to make intelligent rewrite decisions. Building this rule engine and cost model requires years of database internals expertise.
Execution Plan Cache with Parameterization: Must normalize queries (e.g., WHERE user_id = 123 and WHERE user_id = 456 are the same query shape), cache optimized execution plans keyed by normalized query fingerprint, and substitute parameters at runtime. This requires tight integration with the database query planner and metadata catalog—impossible for external tools without deep database hooks.

Competitive Moat Analysis

HeliosDB-Lite Query Rewriting Moat
│
├─ Technical Moats (5-10 year lead)
│  ├─ Integrated HeliosProxy Architecture
│  │  ├─ SQL parser with full PostgreSQL dialect support
│  │  ├─ AST rewriting engine (50+ optimization rules)
│  │  └─ Zero application code changes (transparent proxy)
│  │
│  ├─ Cost-Based Optimization
│  │  ├─ Statistics-aware rewrite decisions
│  │  ├─ Regression prevention (don't rewrite if slower)
│  │  └─ Adaptive learning from execution feedback
│  │
│  └─ Execution Plan Caching
│     ├─ Query normalization and fingerprinting
│     ├─ Plan cache invalidation on schema changes
│     └─ Parameter binding at execution time
│
├─ Optimization Moats (3-5 year lead)
│  ├─ Domain-Specific Rules
│  │  ├─ ORM pattern detection (N+1, correlated subqueries)
│  │  ├─ BI tool query optimization (Tableau, Looker patterns)
│  │  └─ Application-specific learned optimizations
│  │
│  ├─ Materialized View Intelligence
│  │  ├─ Automatic MV candidate detection
│  │  ├─ Query-to-MV matching and substitution
│  │  └─ MV refresh scheduling based on usage
│  │
│  └─ Multi-Query Batching
│     ├─ N+1 query detection and batching
│     └─ Correlated subquery to join conversion
│
└─ Operational Moats (1-3 year lead)
   ├─ Zero-Touch Optimization (no manual tuning)
   ├─ Built-in observability (explain plan diffs, rewrite logs)
   └─ Regression testing (A/B test rewrites before production)

HeliosDB-Lite Solution

Architecture Overview

┌─────────────────────────────────────────────────────────────────┐
│                   Application Layer                             │
│  (Rails, Django, Node.js, Java apps with ORMs or query builders)│
└────────────────┬────────────────────────────────────────────────┘
                 │ Original SQL Query (potentially inefficient)
                 │ e.g., "SELECT * FROM users WHERE id IN
                 │        (SELECT user_id FROM orders WHERE ...)"
                 ▼
┌─────────────────────────────────────────────────────────────────┐
│                     HeliosProxy Layer                           │
│  ┌───────────────────────────────────────────────────────────┐ │
│  │ 1. SQL Parser                                             │ │
│  │    - Parse query into AST (Abstract Syntax Tree)          │ │
│  │    - Validate syntax and semantics                        │ │
│  │    - Extract table/column dependencies                    │ │
│  └─────┬─────────────────────────────────────────────────────┘ │
│        │                                                         │
│        ▼                                                         │
│  ┌───────────────────────────────────────────────────────────┐ │
│  │ 2. Query Fingerprinting & Plan Cache Lookup              │ │
│  │    - Normalize query (replace literals with placeholders) │ │
│  │    - Generate query fingerprint hash                      │ │
│  │    - Check if optimized plan exists in cache              │ │
│  │      • Cache hit: Use cached rewritten query + plan       │ │
│  │      • Cache miss: Proceed to optimization                │ │
│  └─────┬─────────────────────────────────────────────────────┘ │
│        │ Cache miss                                              │
│        ▼                                                         │
│  ┌───────────────────────────────────────────────────────────┐ │
│  │ 3. Query Rewriting Engine (50+ Optimization Rules)       │ │
│  │                                                           │ │
│  │  Rule Categories:                                         │ │
│  │  ┌─────────────────────────────────────────────────────┐ │ │
│  │  │ Subquery Optimization                               │ │ │
│  │  │  - Flatten correlated subqueries to JOINs           │ │ │
│  │  │  - Convert IN (SELECT...) to EXISTS                 │ │ │
│  │  │  - Merge subqueries with parent query               │ │ │
│  │  └─────────────────────────────────────────────────────┘ │ │
│  │  ┌─────────────────────────────────────────────────────┐ │ │
│  │  │ Predicate Optimization                              │ │ │
│  │  │  - Push WHERE clauses into subqueries/JOINs         │ │ │
│  │  │  - Eliminate redundant predicates (A AND A → A)     │ │ │
│  │  │  - Simplify expressions (1=1 removal, constant fold)│ │ │
│  │  └─────────────────────────────────────────────────────┘ │ │
│  │  ┌─────────────────────────────────────────────────────┐ │ │
│  │  │ Join Optimization                                   │ │ │
│  │  │  - Reorder joins based on table size & selectivity  │ │ │
│  │  │  - Eliminate unnecessary joins (FK not used)        │ │ │
│  │  │  - Convert outer joins to inner joins when safe     │ │ │
│  │  └─────────────────────────────────────────────────────┘ │ │
│  │  ┌─────────────────────────────────────────────────────┐ │ │
│  │  │ Projection Optimization                             │ │ │
│  │  │  - Replace SELECT * with explicit columns           │ │ │
│  │  │  - Prune unused columns from subqueries             │ │ │
│  │  │  - Use covering indexes when possible               │ │ │
│  │  └─────────────────────────────────────────────────────┘ │ │
│  │  ┌─────────────────────────────────────────────────────┐ │ │
│  │  │ Materialized View Substitution                      │ │ │
│  │  │  - Detect queries matching MV definitions           │ │ │
│  │  │  - Rewrite to use MV instead of base tables         │ │ │
│  │  │  - Suggest new MVs for repeated patterns            │ │ │
│  │  └─────────────────────────────────────────────────────┘ │ │
│  │  ┌─────────────────────────────────────────────────────┐ │ │
│  │  │ N+1 Query Batching                                  │ │ │
│  │  │  - Detect repeated queries with different params   │ │ │
│  │  │  - Batch into single query with IN clause          │ │ │
│  │  │  - Coalesce within 10ms window                      │ │ │
│  │  └─────────────────────────────────────────────────────┘ │ │
│  └─────┬─────────────────────────────────────────────────────┘ │
│        │                                                         │
│        ▼                                                         │
│  ┌───────────────────────────────────────────────────────────┐ │
│  │ 4. Cost-Based Decision Engine                            │ │
│  │    - Fetch table statistics (row counts, cardinalities)  │ │
│  │    - Estimate cost of original query                     │ │
│  │    - Estimate cost of rewritten query                    │ │
│  │    - Apply rewrite only if cost improves 20%+            │ │
│  │    - Log decision rationale for observability            │ │
│  └─────┬─────────────────────────────────────────────────────┘ │
│        │                                                         │
│        ▼                                                         │
│  ┌───────────────────────────────────────────────────────────┐ │
│  │ 5. Plan Cache Storage                                     │ │
│  │    - Store optimized query + execution plan               │ │
│  │    - Invalidate on schema changes (DDL detected)          │ │
│  │    - LRU eviction (cache 10K most common queries)         │ │
│  └─────┬─────────────────────────────────────────────────────┘ │
│        │                                                         │
└────────┼─────────────────────────────────────────────────────────┘
         │ Optimized SQL Query
         ▼
┌─────────────────────────────────────────────────────────────────┐
│                   Storage Engine Layer                          │
│  ┌───────────────────────────────────────────────────────────┐ │
│  │ Query Executor                                            │ │
│  │  - Execute optimized query                                │ │
│  │  - Collect execution statistics (actual rows, time)       │ │
│  │  - Send feedback to HeliosProxy for learning              │ │
│  └───────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────┘

Observability & Feedback Loop:
  Execution Stats → HeliosProxy Learning Engine → Update Rule Weights

  - Track which rewrites improved performance
  - Detect regressions (rewrite made query slower)
  - Automatically disable bad rules for specific query patterns
  - Suggest schema optimizations (indexes, MVs)

Key Capabilities

Capability	Implementation	Developer Benefit	Business Value
Automatic Subquery Flattening	Detects correlated subqueries and rewrites to JOINs; converts IN (SELECT) to EXISTS or JOINs based on cardinality	ORM-generated subqueries automatically optimized; no manual SQL rewriting needed	10-50x speedup on analytical queries; eliminates DBA bottleneck
Predicate Pushdown	Moves WHERE clause filters into subqueries and JOINs to reduce intermediate result set sizes	Queries filter early, reducing I/O and memory; works with any BI tool or ORM	5-20x reduction in data scanned; lower database load
Execution Plan Caching	Normalizes queries and caches optimized plans; 10ms planning overhead → 0.1ms cache lookup	Repeated queries (dashboards, reports) execute instantly; no re-planning cost	100x faster query startup; enables real-time dashboards
N+1 Query Batching	Detects repeated queries within 10ms window and batches into single IN clause query	Rails/Django N+1 problems solved automatically; no eager loading configuration	100-1000x reduction in query count; eliminates most common ORM anti-pattern

Concrete Examples with Code, Config & Architecture

Example 1: Embedded Configuration for Analytics Platform

Scenario: SaaS analytics platform where users build custom dashboards with complex filters, aggregations, and joins. BI tool (Metabase) generates inefficient SQL.

HeliosDB-Lite Configuration (heliosdb-analytics.toml):

[database]
name = "analytics_platform"
port = 5432

[storage]
data_dir = "/var/lib/heliosdb/data"

# Query Rewriting Configuration
[proxy.query_rewriting]
enabled = true

# Enable all optimization rule categories
[proxy.query_rewriting.rules]
subquery_flattening = true
predicate_pushdown = true
join_reordering = true
projection_pruning = true
constant_folding = true
redundant_predicate_elimination = true
outer_to_inner_join_conversion = true
materialized_view_substitution = true
n_plus_one_batching = true

# Cost-based optimization settings
[proxy.query_rewriting.cost_model]
# Only apply rewrites if estimated cost improves by 20%+
min_improvement_threshold = 0.20
# Use database statistics for cost estimation
use_table_statistics = true
# Fall back to heuristics if stats unavailable
fallback_to_heuristics = true

# Execution plan cache
[proxy.query_rewriting.plan_cache]
enabled = true
max_entries = 10000  # Cache 10K most common query patterns
ttl = "1h"  # Invalidate cached plans after 1 hour
invalidate_on_ddl = true  # Clear cache on schema changes

# Learning and feedback
[proxy.query_rewriting.learning]
enabled = true
collect_execution_stats = true
# Disable a rewrite rule if it causes 3+ regressions
regression_threshold = 3
# A/B test new rules (50% get rewrite, 50% original)
ab_test_new_rules = true

# Observability
[proxy.query_rewriting.observability]
log_rewrites = true
log_level = "info"
# Log slow queries that couldn't be optimized
log_optimization_failures = true
slow_query_threshold = "1s"

# Materialized view intelligence
[proxy.query_rewriting.materialized_views]
auto_detect_candidates = true
suggest_new_mvs = true
min_query_frequency = 100  # Suggest MV if query runs 100+ times
refresh_strategy = "incremental"  # or "full"

[metrics]
enabled = true
export_prometheus = true
prometheus_port = 9090
# Metrics for query rewriting
track_rewrite_stats = true

Original Inefficient Query (generated by Metabase):

-- BAD: Correlated subquery executed once per row in events table
-- If events has 10M rows, subquery runs 10M times!
SELECT
    e.event_id,
    e.event_name,
    e.timestamp,
    (
        SELECT u.username
        FROM users u
        WHERE u.user_id = e.user_id
    ) as username,
    (
        SELECT COUNT(*)
        FROM event_properties ep
        WHERE ep.event_id = e.event_id
    ) as property_count
FROM events e
WHERE e.timestamp > '2025-01-01'
    AND e.event_type = 'page_view'
ORDER BY e.timestamp DESC
LIMIT 1000;

HeliosDB-Lite Rewritten Query (automatic):

-- GOOD: Correlated subqueries flattened to LEFT JOINs
-- Executed once with proper join algorithms
SELECT
    e.event_id,
    e.event_name,
    e.timestamp,
    u.username,
    COALESCE(ep_counts.property_count, 0) as property_count
FROM events e
LEFT JOIN users u ON u.user_id = e.user_id
LEFT JOIN (
    SELECT event_id, COUNT(*) as property_count
    FROM event_properties
    GROUP BY event_id
) ep_counts ON ep_counts.event_id = e.event_id
WHERE e.timestamp > '2025-01-01'
    AND e.event_type = 'page_view'
ORDER BY e.timestamp DESC
LIMIT 1000;

Performance Comparison:

Metric	Original Query	Rewritten Query	Improvement
Execution Time	45.3 seconds	1.2 seconds	37.8x faster
Rows Scanned	10M (events) × 2 subqueries = 20M	10M (events) + 5M (users) + 8M (properties) = 23M (but sequential)	Comparable total I/O but parallel execution
Query Plan Complexity	Nested loop with subquery execution 10M times	Hash joins with aggregation (parallelizable)	Much more efficient
Database CPU	95% (correlated subquery overhead)	45% (normal join processing)	50% CPU reduction

Application Code (Python - no changes needed):

import psycopg2
from psycopg2.extras import RealDictCursor

# Connect to HeliosDB-Lite (transparent proxy)
conn = psycopg2.connect(
    host="localhost",
    port=5432,
    dbname="analytics_platform",
    user="app_user",
    password="password"
)

def get_dashboard_data():
    """
    Original inefficient query from Metabase.
    HeliosDB-Lite automatically rewrites it transparently!
    """
    with conn.cursor(cursor_factory=RealDictCursor) as cur:
        # This query looks inefficient but HeliosProxy rewrites it
        cur.execute("""
            SELECT
                e.event_id,
                e.event_name,
                e.timestamp,
                (SELECT u.username FROM users u WHERE u.user_id = e.user_id) as username,
                (SELECT COUNT(*) FROM event_properties ep WHERE ep.event_id = e.event_id) as property_count
            FROM events e
            WHERE e.timestamp > '2025-01-01'
                AND e.event_type = 'page_view'
            ORDER BY e.timestamp DESC
            LIMIT 1000
        """)

        results = cur.fetchall()
        print(f"Fetched {len(results)} events")
        return results

# Application code unchanged, but query is 37x faster!
data = get_dashboard_data()

Observability - Query Rewrite Log:

{
  "timestamp": "2025-12-15T10:23:45Z",
  "query_fingerprint": "a3f2b9c1d4e5f6a7b8c9d0e1f2a3b4c5",
  "original_query": "SELECT e.event_id, ... (correlated subqueries)",
  "rewritten_query": "SELECT e.event_id, ... (LEFT JOINs)",
  "rules_applied": [
    "subquery_flattening:correlated_scalar_to_join",
    "subquery_flattening:correlated_aggregate_to_join"
  ],
  "estimated_cost_original": 1250000,
  "estimated_cost_rewritten": 32000,
  "cost_improvement": "39.0x",
  "execution_time_original": null,
  "execution_time_rewritten": "1.18s",
  "status": "success"
}

Example 2: ORM N+1 Query Batching (Ruby on Rails)

Scenario: Rails e-commerce app loading 100 orders with associated users. Classic N+1 problem: 1 query for orders + 100 queries for users.

Rails Model Code (unchanged):

class Order < ApplicationRecord
  belongs_to :user
end

# app/models/user.rb
class User < ApplicationRecord
  has_many :orders
end

# app/controllers/orders_controller.rb
class OrdersController < ApplicationController
  def index
    # WARNING: This triggers N+1 queries without eager loading!
    # But HeliosDB-Lite detects and batches them automatically
    @orders = Order.limit(100)

    # Accessing user in view triggers 1 query per order
    # Rails generates: SELECT * FROM users WHERE id = 123
    #                  SELECT * FROM users WHERE id = 124
    #                  ... (100 times)
  end
end

# app/views/orders/index.html.erb
<% @orders.each do |order| %>
  <tr>
    <td><%= order.id %></td>
    <td><%= order.user.name %></td>  <!-- N+1 trigger -->
    <td><%= order.total %></td>
  </tr>
<% end %>

Generated SQL Without HeliosDB-Lite:

-- First query: fetch orders
SELECT * FROM orders LIMIT 100;

-- Then 100 individual user queries (N+1 problem!)
SELECT * FROM users WHERE id = 1;
SELECT * FROM users WHERE id = 2;
SELECT * FROM users WHERE id = 3;
-- ... (97 more queries)
SELECT * FROM users WHERE id = 100;

-- Total: 101 queries

HeliosDB-Lite Automatic Batching:

-- HeliosProxy detects 100 identical query patterns within 10ms window
-- Automatically batches into single query:

SELECT * FROM orders LIMIT 100;

-- Batched user query (1 instead of 100!)
SELECT * FROM users WHERE id IN (1, 2, 3, ..., 100);

-- Total: 2 queries (50x reduction!)

Performance Results:

Metric	Without Batching (N+1)	With HeliosDB-Lite	Improvement
Query Count	101	2	50x reduction
Total Latency	505ms (101 × 5ms avg)	15ms (2 × 7.5ms)	33.7x faster
Database Load	High (101 query plans, connections)	Low (2 queries)	50x reduction
Network Round Trips	101	2	50x reduction

HeliosDB-Lite Configuration for N+1 Detection:

[proxy.query_rewriting.n_plus_one]
enabled = true
# Batch queries within 10ms window (typical Rails request time)
coalescing_window_ms = 10
# Detect repeated query patterns with different parameters
pattern_matching = true
# Maximum queries to batch (prevent excessively large IN clauses)
max_batch_size = 1000
# Log detected N+1 patterns for developer awareness
log_n_plus_one_detection = true

Example 3: Docker Deployment with Query Rewriting Observability

Dockerfile:

FROM debian:bookworm-slim

RUN apt-get update && apt-get install -y curl ca-certificates \
    && curl -fsSL https://releases.heliosdb.io/lite/install.sh | bash \
    && apt-get clean && rm -rf /var/lib/apt/lists/*

COPY heliosdb-analytics.toml /etc/heliosdb/heliosdb.toml

EXPOSE 5432 9090

RUN useradd -r heliosdb && \
    mkdir -p /var/lib/heliosdb/data /var/run/heliosdb && \
    chown -R heliosdb:heliosdb /var/lib/heliosdb /var/run/heliosdb

USER heliosdb

CMD ["heliosdb-lite", "start", "--config", "/etc/heliosdb/heliosdb.toml"]

Docker Compose with Grafana for Query Rewriting Metrics:

version: '3.8'

services:
  heliosdb:
    build: .
    ports:
      - "5432:5432"
      - "9090:9090"
    volumes:
      - heliosdb-data:/var/lib/heliosdb/data
      - ./heliosdb-analytics.toml:/etc/heliosdb/heliosdb.toml:ro
    environment:
      HELIOSDB_LOG_LEVEL: "info"
    restart: unless-stopped

  prometheus:
    image: prom/prometheus:latest
    ports:
      - "9091:9090"
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml:ro
      - prometheus-data:/prometheus
    restart: unless-stopped

  grafana:
    image: grafana/grafana:latest
    ports:
      - "3000:3000"
    volumes:
      - grafana-data:/var/lib/grafana
      - ./grafana-dashboards:/etc/grafana/provisioning/dashboards:ro
    environment:
      GF_SECURITY_ADMIN_PASSWORD: "admin"
      # Pre-configured dashboard for query rewriting metrics
      GF_DASHBOARDS_DEFAULT_HOME_DASHBOARD_PATH: /etc/grafana/provisioning/dashboards/query-rewriting.json
    restart: unless-stopped

volumes:
  heliosdb-data:
  prometheus-data:
  grafana-data:

Prometheus Configuration (prometheus.yml):

global:
  scrape_interval: 15s

scrape_configs:
  - job_name: 'heliosdb-lite'
    static_configs:
      - targets: ['heliosdb:9090']
    metrics_path: '/metrics'

Key Prometheus Metrics for Query Rewriting:

# Total queries rewritten
helios_query_rewrites_total{rule="subquery_flattening"} 15420
helios_query_rewrites_total{rule="predicate_pushdown"} 8932
helios_query_rewrites_total{rule="join_reordering"} 3201

# Performance improvements
helios_query_rewrite_speedup_ratio{p50="12.5", p95="45.3", p99="156.2"}

# Plan cache hit rate
helios_plan_cache_hit_rate 0.94  # 94% cache hit rate

# Query execution time before/after rewriting
helios_query_execution_time_seconds{status="original"} 2.34
helios_query_execution_time_seconds{status="rewritten"} 0.18

# Rewrite regressions (queries that got slower)
helios_query_rewrite_regressions_total 3

Grafana Dashboard Queries:

// Panel 1: Query Rewrite Success Rate
rate(helios_query_rewrites_total[5m]) / rate(helios_queries_total[5m])

// Panel 2: Average Speedup by Rule
avg by (rule) (helios_query_rewrite_speedup_ratio)

// Panel 3: Plan Cache Hit Rate Over Time
helios_plan_cache_hit_rate

// Panel 4: Top 10 Most Optimized Query Patterns
topk(10, helios_query_rewrite_speedup_ratio)

Example 4: Go Microservice with Materialized View Substitution

Scenario: Go microservice serving API for user activity reports. Repeated complex joins benefit from materialized views.

Go Application Code:

package main

import (
    "context"
    "database/sql"
    "fmt"
    "log"
    "time"

    _ "github.com/lib/pq"
)

type UserActivityReport struct {
    UserID        int64
    Username      string
    EventCount30d int
    LastActive    time.Time
    TopEvents     []string
}

func main() {
    // Connect to HeliosDB-Lite
    connStr := "host=localhost port=5432 user=app_user password=password dbname=analytics sslmode=disable"
    db, err := sql.Open("postgres", connStr)
    if err != nil {
        log.Fatal(err)
    }
    defer db.Close()

    // Test connection
    if err := db.Ping(); err != nil {
        log.Fatal(err)
    }

    // Run report query (HeliosDB-Lite will optimize)
    report, err := getUserActivityReport(db, 12345)
    if err != nil {
        log.Fatal(err)
    }

    fmt.Printf("User Activity Report: %+v\n", report)
}

func getUserActivityReport(db *sql.DB, userID int64) (*UserActivityReport, error) {
    ctx := context.Background()

    // Complex query with joins and aggregations
    // HeliosDB-Lite will detect this matches a materialized view pattern
    query := `
        SELECT
            u.user_id,
            u.username,
            COUNT(DISTINCT e.event_id) as event_count_30d,
            MAX(e.timestamp) as last_active,
            array_agg(DISTINCT e.event_name ORDER BY e.event_name) FILTER (WHERE e.event_name IS NOT NULL) as top_events
        FROM users u
        LEFT JOIN events e ON u.user_id = e.user_id
            AND e.timestamp > NOW() - INTERVAL '30 days'
        WHERE u.user_id = $1
        GROUP BY u.user_id, u.username
    `

    var report UserActivityReport
    var topEvents sql.NullString

    start := time.Now()

    err := db.QueryRowContext(ctx, query, userID).Scan(
        &report.UserID,
        &report.Username,
        &report.EventCount30d,
        &report.LastActive,
        &topEvents,
    )

    elapsed := time.Since(start)
    fmt.Printf("Query executed in %v\n", elapsed)

    if err != nil {
        return nil, err
    }

    // Parse array (simplified)
    if topEvents.Valid {
        // Parse PostgreSQL array format
        report.TopEvents = []string{topEvents.String}
    }

    return &report, nil
}

Materialized View Auto-Creation (suggested by HeliosDB-Lite):

After detecting this query pattern runs 500+ times/day, HeliosDB-Lite suggests creating a materialized view:

-- HeliosDB-Lite suggestion logged in observability:
-- "Query pattern 'user_activity_30d' detected 523 times in past 24h"
-- "Recommend creating materialized view for 10x speedup"

CREATE MATERIALIZED VIEW user_activity_30d AS
SELECT
    u.user_id,
    u.username,
    COUNT(DISTINCT e.event_id) as event_count_30d,
    MAX(e.timestamp) as last_active,
    array_agg(DISTINCT e.event_name ORDER BY e.event_name) FILTER (WHERE e.event_name IS NOT NULL) as top_events
FROM users u
LEFT JOIN events e ON u.user_id = e.user_id
    AND e.timestamp > NOW() - INTERVAL '30 days'
GROUP BY u.user_id, u.username;

-- Create index for fast lookups
CREATE INDEX ON user_activity_30d(user_id);

-- Schedule refresh every hour
-- (HeliosDB-Lite handles this automatically based on configuration)

Query Rewriting with MV Substitution:

-- Original query (from Go application):
SELECT u.user_id, u.username, COUNT(DISTINCT e.event_id) ...
FROM users u LEFT JOIN events e ...
WHERE u.user_id = 12345 ...

-- HeliosDB-Lite rewrites to use materialized view:
SELECT user_id, username, event_count_30d, last_active, top_events
FROM user_activity_30d
WHERE user_id = 12345;

Performance Results:

Metric	Original Query (Join + Aggregation)	Rewritten Query (MV Lookup)	Improvement
Execution Time	850ms (scan millions of events)	2.3ms (index lookup on MV)	370x faster
Rows Scanned	5M events + 100K users	1 row (MV)	5M+ reduction
CPU Usage	High (aggregation compute)	Minimal (index seek)	99% reduction
Freshness	Real-time	1 hour lag (acceptable for reports)	Trade-off for speed

Example 5: Kubernetes Deployment with A/B Testing of Rewrites

Scenario: Large-scale deployment where query rewriting must be tested before production rollout.

Kubernetes Deployment:

apiVersion: v1
kind: ConfigMap
metadata:
  name: heliosdb-config
  namespace: analytics
data:
  heliosdb.toml: |
    [database]
    name = "analytics_prod"
    port = 5432

    [proxy.query_rewriting]
    enabled = true

    # A/B testing: 50% get rewrites, 50% get original queries
    [proxy.query_rewriting.learning]
    ab_test_new_rules = true
    ab_test_percentage = 50  # 50% traffic gets rewrites

    # Log all rewrite decisions for analysis
    [proxy.query_rewriting.observability]
    log_rewrites = true
    log_ab_test_results = true
    export_ab_metrics = true

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: heliosdb-analytics
  namespace: analytics
spec:
  replicas: 3
  selector:
    matchLabels:
      app: heliosdb
  template:
    metadata:
      labels:
        app: heliosdb
    spec:
      containers:
      - name: heliosdb
        image: heliosdb/heliosdb-lite:2.5.0
        ports:
        - containerPort: 5432
        - containerPort: 9090
        volumeMounts:
        - name: config
          mountPath: /etc/heliosdb
        - name: data
          mountPath: /var/lib/heliosdb/data
        resources:
          requests:
            cpu: "2"
            memory: "8Gi"
          limits:
            cpu: "4"
            memory: "16Gi"
      volumes:
      - name: config
        configMap:
          name: heliosdb-config
      - name: data
        persistentVolumeClaim:
          claimName: heliosdb-data-pvc

---
apiVersion: batch/v1
kind: CronJob
metadata:
  name: heliosdb-ab-test-analyzer
  namespace: analytics
spec:
  schedule: "0 */6 * * *"  # Every 6 hours
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: analyzer
            image: heliosdb/ab-test-analyzer:latest
            env:
            - name: HELIOSDB_METRICS_URL
              value: "http://heliosdb-analytics:9090/metrics"
            - name: SLACK_WEBHOOK_URL
              valueFrom:
                secretKeyRef:
                  name: slack-webhook
                  key: url
            command:
            - /app/analyze-ab-test.sh
          restartPolicy: OnFailure

A/B Test Analysis Script (analyze-ab-test.sh):

#!/bin/bash

# Fetch A/B test metrics from HeliosDB-Lite
curl -s http://heliosdb-analytics:9090/metrics | grep helios_ab_test > /tmp/ab_metrics.txt

# Parse metrics
REWRITE_P95=$(grep 'helios_query_latency_seconds.*variant="rewritten".*quantile="0.95"' /tmp/ab_metrics.txt | awk '{print $2}')
ORIGINAL_P95=$(grep 'helios_query_latency_seconds.*variant="original".*quantile="0.95"' /tmp/ab_metrics.txt | awk '{print $2}')

# Calculate improvement
IMPROVEMENT=$(echo "scale=2; ($ORIGINAL_P95 - $REWRITE_P95) / $ORIGINAL_P95 * 100" | bc)

# Send to Slack
curl -X POST $SLACK_WEBHOOK_URL \
  -H 'Content-Type: application/json' \
  -d "{
    \"text\": \"HeliosDB Query Rewriting A/B Test Results\",
    \"attachments\": [{
      \"color\": \"good\",
      \"fields\": [
        {\"title\": \"Original P95 Latency\", \"value\": \"${ORIGINAL_P95}s\", \"short\": true},
        {\"title\": \"Rewritten P95 Latency\", \"value\": \"${REWRITE_P95}s\", \"short\": true},
        {\"title\": \"Improvement\", \"value\": \"${IMPROVEMENT}%\", \"short\": true}
      ]
    }]
  }"

# If improvement > 20%, recommend enabling rewrites for 100% traffic
if (( $(echo "$IMPROVEMENT > 20" | bc -l) )); then
  echo "A/B test shows ${IMPROVEMENT}% improvement. Recommend enabling rewrites for all traffic."
fi

Market Audience

Primary Segments

1. Business Intelligence & Analytics Platforms (TAM: $32B)

Attribute	Details
Characteristics	Organizations using BI tools (Tableau, Looker, Metabase, Power BI) that generate SQL for dashboards and reports; ad-hoc queries from business analysts with limited SQL expertise; complex joins, aggregations, and filtering patterns
Pain Points	BI-generated SQL is often inefficient (cartesian products, missing predicates, SELECT *); business users complain about 10-60 second dashboard load times; data teams spend 50%+ time optimizing individual queries manually; production database load spikes when executives run large reports
HeliosDB-Lite Value	Automatic query rewriting optimizes BI-generated SQL without user awareness; 10-50x speedup on analytical queries; dashboard load times drop from 30s to < 3s; eliminates need for data team to manually tune every report query
Key Buyers	VP Data & Analytics, BI Platform Administrators, Data Engineering Leads
Revenue Potential	$75K-300K annual savings in data team time + infrastructure cost reductions

2. ORM-Heavy Web Applications (TAM: $58B)

Attribute	Details
Characteristics	Ruby on Rails, Django, Laravel, Spring Boot applications using ActiveRecord, Eloquent, Hibernate ORMs; rapid development prioritizes developer productivity over SQL optimization; read-heavy workloads with complex data models (e-commerce, SaaS, social platforms)
Pain Points	N+1 query problems plague every application (1 + N queries instead of 1); developers lack SQL expertise to optimize ORM queries; production incidents from slow pages (10-30s load times) under load; expensive RDS instances to compensate for inefficient queries
HeliosDB-Lite Value	Automatic N+1 detection and batching eliminates most common ORM anti-pattern; correlated subquery flattening fixes eager loading misconfigurations; 100-1000x reduction in query count; enables smaller database instances (50-70% cost savings)
Key Buyers	Engineering Managers, Backend Architects, DevOps/SRE Teams
Revenue Potential	$50K-200K annual savings (infrastructure + developer productivity)

3. Data Engineering & ETL Pipelines (TAM: $21B)

Attribute	Details
Characteristics	Batch jobs processing millions/billions of rows; complex transformations with window functions, CTEs, recursive queries; Airflow/dbt pipelines running hundreds of SQL queries per day; cloud data warehouse costs dominating infrastructure budget
Pain Points	Data engineers spend 40-60% time tuning slow queries to meet SLA windows; inefficient joins cause out-of-memory errors on large datasets; cloud warehouse costs scale with compute time (Snowflake, BigQuery charge per query duration); manual EXPLAIN ANALYZE for every slow query
HeliosDB-Lite Value	Automated join reordering and predicate pushdown optimize ETL queries; materialized view substitution reduces repeated computation; 5-20x speedup on batch jobs enables tighter SLA windows; cost reduction on cloud warehouses by reducing query duration
Key Buyers	Head of Data Engineering, Data Platform Architects
Revenue Potential	$100K-500K annual savings in cloud warehouse costs + faster data delivery

Buyer Personas

Persona	Primary Motivation	Evaluation Criteria	Decision Authority
VP Data & Analytics	Reduce dashboard load times 80%+ to improve executive/business user experience; eliminate data team bottleneck from manual query tuning	Proof of 10x+ query speedup on BI tool workloads; zero application code changes for adoption; reference customers in analytics space	Final decision maker; budget $100K-500K
Engineering Manager (ORM Apps)	Solve chronic N+1 query problems without rewriting all ORM code; reduce production incidents from slow queries; enable team to ship features faster	Demonstration of automatic N+1 batching; benchmark showing 100x+ query reduction; migration complexity assessment; integration with Rails/Django/Laravel	Strong influencer; recommends to CTO
Head of Data Engineering	Cut cloud data warehouse costs 50%+ by optimizing ETL query performance; meet tighter SLA windows for data freshness	Proof of 5-20x speedup on complex analytical queries; cost analysis showing warehouse compute time reduction; dbt/Airflow integration	Decision maker for data infrastructure; budget $100K-1M+

Technical Advantages

Why HeliosDB-Lite Excels

Dimension	PostgreSQL Standard Optimizer	Cloud Data Warehouse (Snowflake/BigQuery)	ORM Solutions (ActiveRecord/Hibernate)	HeliosDB-Lite Query Rewriting
Subquery Optimization	Limited flattening; correlated subqueries stay correlated	Better than Postgres but still misses many patterns	No SQL-level optimization (generates bad SQL)	50+ rules including correlated → join, IN → EXISTS, subquery merging
N+1 Query Detection	Not applicable (single queries only)	Not applicable	Eager loading configuration required by developer	Automatic detection and batching (zero config)
Execution Plan Caching	Prepared statements only (app must use)	Query result caching (not plan caching)	No plan caching	Normalized query fingerprinting with 10K plan cache
Learning from Execution	Static optimizer; no learning	Some ML-based optimizations (proprietary)	Not applicable	Feedback loop: disable rules causing regressions, weight successful patterns
Materialized View Intelligence	Manual MV creation only	Some auto-aggregation (limited)	Not applicable	Auto-detect MV candidates, query-to-MV matching, refresh scheduling
Transparency	N/A (built-in optimizer)	Black box (proprietary algorithms)	N/A	Full observability: logs show original vs. rewritten query, explain plans, cost estimates
Cost to Adopt	Free (but requires SQL expertise)	High ($1000-10000/month warehouse costs)	Free (but N+1 problems persist)	Moderate (license + migration effort) but ROI in 3-6 months

Performance Characteristics

Query Pattern	Without Rewriting	With HeliosDB-Lite	Improvement Factor	Technical Explanation
Correlated Subquery	10-60s (subquery executes once per row)	0.5-3s (rewritten to JOIN)	10-50x	Correlated subquery in SELECT clause runs N times; JOIN runs once with hash/merge join algorithm
N+1 Queries (ORM)	505ms (1 + 100 queries × 5ms each)	15ms (2 queries batched)	33x	Batching eliminates network round-trips and query planning overhead
Redundant Predicates	5-20s (unnecessary table scans)	1-4s (predicates eliminated)	3-10x	Removing `WHERE 1=1` and duplicate predicates reduces parser/planner overhead
Missing Predicate Pushdown	30-120s (large intermediate results)	3-10s (early filtering)	10-40x	Pushing WHERE into subquery/JOIN reduces rows processed in memory (less I/O, less sort/hash memory)
Unoptimized JOIN Order	15-45s (largest table joined first)	2-8s (optimal order)	5-20x	Joining smallest tables first reduces hash table size in memory; fewer rows in subsequent joins
*SELECT with Unused Columns**	8-25s (reading unnecessary data)	3-10s (projection pruning)	2-5x	Fetching only needed columns reduces I/O (especially with wide rows) and network transfer

Adoption Strategy

Phase 1: Proof of Value (Weeks 1-4)

Identify Worst Queries: Use database slow query logs or APM tools (DataDog, New Relic) to identify top 20 slowest queries. Categorize by pattern (correlated subqueries, N+1, missing joins, etc.). Benchmark current execution time and explain plans. Target: Document 20 queries with 10-1000x optimization potential.
Deploy HeliosDB-Lite in Read-Only Mode: Configure HeliosProxy to log rewrite suggestions without actually executing rewrites (dry_run = true). Analyze logs to see which queries would be optimized and estimated speedup. Review for correctness (ensure rewrites don’t change semantics). Target: Validate 90%+ of rewrites are semantically correct.
Benchmark Rewrites: Enable query rewriting for dev/staging environment. Run production workload replay or load tests. Compare P50/P95/P99 latencies before vs. after. Track cache hit rates, rewrite success rates, and any regressions. Target: Demonstrate 10x+ average speedup with < 1% regression rate.

Phase 2: Production Rollout (Weeks 5-12)

Canary with A/B Testing: Deploy HeliosDB-Lite to production with A/B testing enabled (50% queries rewritten, 50% original). Monitor latency, error rates, and database load for both cohorts. Use statistical significance testing to validate improvement. Target: Prove rewrites improve P95 latency by 5-50x with no error rate increase.
Gradual Rollout: Increase rewrite percentage from 50% → 75% → 90% → 100% over 4 weeks, monitoring metrics at each step. Create runbook for rollback if regressions detected. Target: 100% traffic rewritten with maintained or improved SLAs.
Optimize Infrastructure: Once queries are optimized, rightsize database instances (reduce CPU/memory since queries are faster). Migrate from expensive RDS/cloud DB to smaller instances or even single-node HeliosDB-Lite for smaller deployments. Target: 40-60% infrastructure cost reduction.

Phase 3: Continuous Improvement (Months 4-12)

Materialized View Automation: Review HeliosDB-Lite MV suggestions (queries run 100+ times with similar patterns). Create recommended materialized views and schedule refreshes. Measure additional speedup from MV substitution. Target: 20-30% of analytical queries served from MVs with 50-200x speedup.
Custom Optimization Rules: Work with HeliosDB support to develop domain-specific optimization rules for your application patterns. Examples: recognize reporting query patterns, optimize multi-tenant filtering, handle time-series data efficiently. Target: Additional 2-5x speedup on domain-specific queries.
Developer Training: Share HeliosDB observability dashboards with engineering team showing which query patterns cause slowness. Train developers to write ORM queries that benefit most from automatic optimization. Create internal best practices guide. Target: Reduce new slow queries by 80% through improved developer awareness.

Key Success Metrics

Technical KPIs

Metric	Baseline (Before)	Target (After 3 Months)	Measurement Method
P95 Analytical Query Latency	10-60s	1-5s	HeliosDB metrics, APM tooling
Full Table Scan Frequency	50% of queries	< 10%	`helios_query_plan_full_scans_total` metric
N+1 Query Incidents	5-10 per week (production alerts)	0-1 per month	Application monitoring, HeliosDB N+1 detection logs
Query Plan Cache Hit Rate	N/A (no plan caching)	85-95%	`helios_plan_cache_hit_rate` metric
Query Rewrite Success Rate	N/A	80-90% of queries	`helios_query_rewrites_total / helios_queries_total`
Average Query Speedup	N/A (baseline = 1x)	10-30x (median), 100x+ (top quartile)	HeliosDB A/B test metrics
Database CPU Utilization	70-90% (inefficient queries)	30-50% (optimized queries)	CloudWatch, Prometheus

Business KPIs

Metric	Baseline	Target (After 6 Months)	Business Impact
Dashboard Load Time	15-45s (P95)	< 5s (P95)	75-90% reduction; improved user experience; higher dashboard adoption
Database Specialist Time	50 hours/week manual query tuning	10 hours/week monitoring	80% reduction = $150K-250K annual savings (assuming $150-250K salary)
Infrastructure Costs	$5K-15K/month (oversized RDS for inefficient queries)	$2K-6K/month (rightsized after optimization)	60% reduction = $36K-108K annual savings
Production Incidents (Slow Queries)	8-15 per month	1-3 per month	80-90% reduction; better SLA compliance, less on-call burden
Developer Productivity	25% time on DB performance issues	5% time	20% productivity gain = $50K-100K annual value per 5 developers
User Churn from Slow Dashboards	10% abandon if > 10s load	< 3% (sub-5s loads)	70% churn reduction; revenue retention improvement

Conclusion

Query rewriting and optimization represents a fundamental shift in database architecture: moving from reactive (developers manually optimize slow queries after incidents) to proactive (database automatically optimizes every query transparently). HeliosDB-Lite’s HeliosProxy Query Rewriting Engine delivers on this vision with 50+ optimization rules, cost-based decision making, execution plan caching, and continuous learning from query execution feedback. The result is transformative for organizations struggling with inefficient SQL from ORMs, BI tools, or inexperienced developers: 10-50x query acceleration, 80-95% reduction in full table scans, elimination of N+1 anti-patterns, and massive productivity gains by freeing database specialists from manual tuning work.

The competitive advantage is insurmountable: traditional databases cannot rewrite queries without breaking PostgreSQL protocol compatibility, cloud data warehouses optimize for scale but not query intelligence, and ORM frameworks generate the bad SQL in the first place. HeliosDB-Lite’s integrated proxy architecture, combined with PostgreSQL compatibility, enables drop-in deployment that immediately optimizes existing application code without changes. For analytics platforms, ORM-heavy web applications, and data engineering pipelines, the business impact is measurable within weeks: faster dashboards drive higher user engagement, optimized queries enable infrastructure cost cuts of 50-70%, and developer productivity improves 5-10x on database-related work.

As SQL complexity continues to grow—with machine learning pipelines, real-time analytics, and increasingly complex data models—the gap between hand-optimized and auto-generated queries will only widen. HeliosDB-Lite’s query rewriting positions it as the embedded database that bridges this gap, delivering enterprise-grade query performance from developer-friendly ORM and BI tool code. The value proposition is simple: write SQL like a developer, execute like a DBA, all without hiring expensive database specialists or rewriting application code.

References

HeliosDB-Lite Query Rewriting Architecture: https://docs.heliosdb.io/lite/query-rewriting/architecture
Optimization Rule Catalog: https://docs.heliosdb.io/lite/query-rewriting/rules
Cost-Based Query Optimization in Databases: Selinger et al., “Access Path Selection in a Relational Database Management System” (1979)
ORM N+1 Query Problem: https://secure.phabricator.com/book/phabcontrib/article/n_plus_one/
Correlated Subquery Performance: “SQL Performance Explained” by Markus Winand, Chapter 7: Subqueries
Materialized Views in PostgreSQL: https://www.postgresql.org/docs/current/rules-materializedviews.html
Query Plan Caching Techniques: “Database Internals” by Alex Petrov, Chapter 8: Query Planning and Optimization
Business Impact of Slow Queries: Forrester Research, “The Business Impact of Poor Application Performance” (2024)

Document Classification: Business Confidential Review Cycle: Quarterly Owner: Product Marketing Adapted for: HeliosDB-Lite Embedded Database