Operating

Security & privacy

OptiHouse is built to be the lowest-risk tool you can point at a production database. It reads, it never writes, and it asks for the narrowest credentials that still let it do its job.

Read-only, always

OptiHouse only issues SELECT statements against system.*. It never writes rows, never runs DDL and never touches your application tables. The recommended ClickHouse user has readonly = 1, so the database enforces this regardless of what the platform tries to do.

sql

CREATE USER dataeff IDENTIFIED WITH plaintext_password BY '<strong-random>';
GRANT SELECT ON system.* TO dataeff;
ALTER USER dataeff SETTINGS readonly = 1;

-- Verify
INSERT INTO test VALUES (1);   -- should fail
SELECT count() FROM system.parts;  -- should work

What it reads, what it stores

Scans collect aggregated metadata, not your data. From query_log it keeps normalised query patterns and counters — bytes read, durations, row counts — not result sets. From system.parts, system.columns, system.replicas and similar views it keeps sizes, counts and engine metadata. The collected snapshot is what powers recommendations and anomaly diffing.

Query text

Query patterns are stored so the optimizer and fingerprint-drift analyzer can work. Treat the platform's database with the same care as any system that can see your SQL.

How secrets are handled

ClickHouse passwords and SSH private keys are stored server-side in encrypted columns.
Secrets are never returned by the API — GET /connections echoes only host, port, user and a bastion_configured boolean.
SSH tunnels are short-lived: opened per scan, torn down immediately afterwards.
The public optimizer endpoint takes no credentials at all — it analyses SQL text only.

Network posture

Every connectivity mode is outbound from OptiHouse toward your cluster — the platform dials in, your cluster never has to accept an unexpected inbound connection. The long-term target is the pull-based agent: a collector inside your VPC POSTs snapshots out over HTTPS, so there are no inbound ports and no credentials on our side. See Connecting ClickHouse for the full matrix.

What not to do

Don't	Why
Expose ClickHouse directly to the internet	Its HTTP layer has a long history of CVEs — keep it private.
Share write-capable credentials with any tool	Always create a dedicated `readonly = 1` user scoped to `system.*`.
Reuse a personal SSH key for the bastion	Generate a dedicated key on a single restricted `authorized_keys` entry.

Account safety

Platform accounts support email verification, password reset and an audit log of sensitive actions. The public optimizer endpoint is rate-limited per IP and caps input SQL length, so it cannot be used to hammer the service.