July 16, 2026
SELECT * FROM chaos
Helicone allows users to write SQL directly to a shared ClickHouse
Helicone let customers query shared data, and commenters instantly yelled “what could go wrong?”
TLDR: Helicone now lets customers run their own searches on a shared database, while relying on built-in filters to keep each company’s data separated. Commenters were split between “smart setup” and “cool, but one bad query could still ruin everyone’s day,” turning the real debate into safety versus shared-system chaos.
Helicone just did the kind of thing that makes cautious engineers clutch their keyboards: it gave customers a text box to write their own database searches against a shared pile of company data. The company’s big promise is that each customer can only see their own records, thanks to a server-side filter that silently tags every search with that customer’s ID. In plain English: users get freedom, but the database is supposed to act like a bouncer.
And yes, the community absolutely treated this like a live-fire experiment. One camp was impressed that Helicone pushed the safety rules down into the database itself instead of just saying “trust us.” Another camp immediately jumped to the real horror movie villain: not data leaks, but the dreaded “noisy neighbor” problem. As one commenter warned, it’s very easy for one awful search to make the whole system crawl. Translation: even if nobody steals your stuff, somebody can still accidentally set the kitchen on fire.
The replies also had that classic internet mix of helpful and hilariously ominous. One person casually dropped a ClickHouse setting tip, basically saying, “nice try, but here’s an easier way.” Another chimed in with a Snowflake setup that adds even more walls and locks, which gave the whole thread a subtle my bunker is safer than your bunker energy. The vibe? Equal parts admiration, side-eye, and “bold move, let’s see if it survives production.”
Key Points
- •Helicone added an SQL editor called HQL that lets customers run SELECT queries directly against a shared ClickHouse cluster.
- •All organizations’ request data is stored in the same ClickHouse table, request_response_rmt, partitioned logically by an organization_id column.
- •Helicone uses a dedicated ClickHouse user and a row policy with getSetting('SQL_helicone_organization_id') to enforce per-organization row filtering on every SELECT.
- •On ClickHouse Cloud, custom settings must use the SQL_ prefix, so Helicone passes the tenant identifier as SQL_helicone_organization_id on each query.
- •Helicone sets readonly, DDL restrictions, execution time, memory, and result-row limits per query, with the organization ID sourced from its authentication layer rather than customer input.