Is your feature request related to a problem? Please describe.
Step three in abstracting the Osprey codebase away from assuming Druid downstream. Follows #225
The cut-over should enusre that the new backend returns identical responses. Druid's alternative is Clickhouse. ROOST users use it and Coop uses it. Checking for data integrity (null handling, typed entities, FP rounding) as well as prod guarantees (connections, latentcy, through put).
What solution would you like
Build in Clickhouse and test against "prod-like" traffic. (Jetstream can imitate Bluesky traffic)
Key changes expected:
- Integrate Clickhouse backend
- Latency benchmarks at realistic realistic with p50/p95/p99 thresholds
- Capacity comparison against the current deployment
- Good to have: SLOs for the analytics read path
Describe alternatives you have considered
Rely on the integration test suite alone. Rejected — integration tests prove the interface contract holds, not that the backend is fit for production.
Do you have any additional context?
Depends on Step 2. (#225 )
Is your feature request related to a problem? Please describe.
Step three in abstracting the Osprey codebase away from assuming Druid downstream. Follows #225
The cut-over should enusre that the new backend returns identical responses. Druid's alternative is Clickhouse. ROOST users use it and Coop uses it. Checking for data integrity (null handling, typed entities, FP rounding) as well as prod guarantees (connections, latentcy, through put).
What solution would you like
Build in Clickhouse and test against "prod-like" traffic. (Jetstream can imitate Bluesky traffic)
Key changes expected:
Describe alternatives you have considered
Rely on the integration test suite alone. Rejected — integration tests prove the interface contract holds, not that the backend is fit for production.
Do you have any additional context?
Depends on Step 2. (#225 )