Goals

Q4 2026 objectives

Q4 is about getting the smaller JSON events store and our ClickHouse fork into production, while making the fleet easier to operate and customer data easier to delete.

📦 Ship JSON events and the ClickHouse fork - (Driver: Rory Shanks)

Duplicated event data increases storage costs, and the current table is difficult to change at our scale. Native JSON, supported by our fork's optimizations, gives us a smaller and more flexible events store.

What we'll ship:

• The ClickHouse fork on the new events cluster, with production validation and a tested rollback path (Rory Shanks)
• Historical backfill and native JSON support in the app, together with Query Performance (Rory Shanks)
• Team 2 cutover followed by staged customer migration, with measured storage savings and query performance (Rory Shanks)

🗑️ Reliable data deletion - (Driver: Pawel Szczur)

Data is spread across more tables and clusters. We need to know where it lives and reliably delete it when requested.

What we'll ship:

• A map of deletion coverage for person, team, and event data across the fleet (Pawel Szczur)
• Data deletion requests that complete and verify their results with minimal manual intervention, including on the new JSON events schema (Pawel Szczur)

🔐 Secure access and tested upgrades - (Driver: Tommy Gilmore)

We've made progress on token authentication. We should finish removing unnecessary passwords, improve the remaining authentication paths, and test upgrades with our ClickHouse fork.

What we'll ship:

• Token authentication for remaining compatible users, with obsolete passwords removed (Tommy Gilmore)
• Consistent secret management and tested rotation for users that still require passwords (Tommy Gilmore)
• The existing smoke tester running against fork release candidates, including upgrade and downgrade checks (Tommy Gilmore)

🤖 Make ClickHouse operations self-driving - (Driver: Bryan Ciaraldi)

Too much operational work depends on someone noticing a problem and investigating it by hand. Our monitoring, HouseWatch, and MCP should identify recurring problems, explain them, and help us act earlier.

What we'll ship:

• An operational health view that surfaces problems before they become incidents (Bryan Ciaraldi)
• Agent-driven investigation of recurring warnings, with evidence and a proposed next action (Bryan Ciaraldi)
• Fixes for recurring operational problems uncovered through this work (Bryan Ciaraldi)

We'll know it worked when: recurring warnings arrive with enough context to act, and routine investigations need less manual work.

⚙️ Ship the ClickHouse fork with confidence - (Driver: Juho Heikki Kristian Päivärinta)

The fork needs reliable testing and a repeatable release process. Fleet changes should be possible without relying on one person's knowledge.

What we'll ship:

• Release validation that builds on our existing CI and tests the fork on production's ARM64 architecture (Juho Päivärinta)
• A repeatable process for forwarding patches to new ClickHouse releases and publishing tested artifacts (Juho Päivärinta)
• Repeatable fleet workflows for rolling upgrades and instance or disk changes, with health checks before nodes return to service (Juho Päivärinta)

Handbook