Goals

Q4 2026 objectives

Objective 1: Proactively identify and improve suboptimal experiences for our customers Vasco De KrijgerVasco De Krijger

Motivation: Customers sometimes experience slow queries, timeouts and regressions before we notice them. We want to understand their experience, proactively identify optimizations and be able to demonstrate that our improvements help.

What we'll ship:

1. A shared performance dashboard (starting with a subset of customers), giving us insights across different levels (complete experience -> product experience -> query experience), tied to our internal monitoring stack.
2. Surfaced regressions/frustrating paths proactively raised with the team, grounded in tested hypothesis to avoid hallucinations with possible suggestions for fixes.
3. A way to continuously help our customers get to their data in an efficient way (through app, API and MCP), for example by spotting slow (saved) queries and offering (data-backed) ways to make these faster.

Objective 2: Make query-performance experiments easy to run and trust Andy ZhaoAndy Zhao

Motivation: We can already experiment with query variants, but testing ClickHouse versions, sharding and physical data layouts requires more setup. A repeatable environment would let us explore larger improvements and build confidence before production changes.

What we'll ship:

1. A (documented) test environment with representative data distributions and a repeatable way to run experiments.
2. Clear metrics / benchmark results at the end of a test to be able to compare across experiments.

Objective 3: Safely bring the JSON Events Table into production Sandy SpicerSandy Spicer

Motivation: The JSON Events Table offers substantial storage savings. We need to establish compatibility, resolve blocking differences and roll out supported workloads while preserving correctness and a good customer experience.

What we'll ship:

1. A clear before vs after impact assessment of the migration.
2. Workloads migrated to the new JSON Events Table.

Objective 4: Turn HogQL into an extensible optimizing compiler George MunyoroGeorge Munyoro

Motivation: HogQL understands the meaning of queries across PostHog. We want to use that knowledge to automatically improve how those queries execute. A composable optimization pipeline will let engineers build on each other's work, adding independently verified passes that make queries faster and reduce compute costs.

What we'll ship:

1. A composable pass manager with explicit requirements for each pass, automatic handling of invalidated analyses, and verification between passes. Migrate existing transformations while preserving their behavior.
2. A documented workflow for writing optimization passes, with reference implementations, independent tests, and tools to inspect changes and compare correctness and performance.
3. Useful optimization passes built and shipped through this framework, with measured performance benefits and result-equivalence checks. Validate the contribution workflow with a pass written by another engineer.

Handbook

Who are we building for?

Personas

• Primary Personas:
  • Product engineer
    • These are the engineers building the product. Normally full-stack engineers skewing frontend or frontend engineers.
    • Product engineers have more limited time. Need to quickly get high-quality insights to inform what they are building and assess what they've shipped.
  • Product manager (ex-engineer type)
    • Supports the product teams (engineers, PMs, designers) to build the best products. They guide the product roadmap by speaking to customers and diving into the data.
    • Product managers are the power-users of analytics (further evidence in the data analysis of paying users). They have desire and the time to go significantly deeper into the data.
• Limited focus:
  • Growth engineer
• Not a focus but should be usable by:
  • Everyone in the product team (less technical PMs, designers)
  • Marketing
  • Leadership team