Reference · built on requestConnectorDatabases & warehouses

ClickHouse

Columnar tables and query results from ClickHouse over the HTTP interface on port 8123 or the native protocol on port 9000.

Request accessPricing ↗

About

ClickHouse is an open-source column-oriented database for analytic queries from ClickHouse, self-hosted or run as ClickHouse Cloud. The HTTP interface listens on port 8123, with 8443 for HTTPS: a query travels as a URL parameter or a POST body, results default to TabSeparated unless a FORMAT clause says otherwise, and a GET request is treated as readonly. The native protocol on port 9000, or 9440 with TLS, serves clickhouse-client and language clients such as clickhouse-go. Tables in the MergeTree family store data in immutable parts merged in the background, sorted by the ORDER BY key and indexed by granules of 8192 rows. Access is managed in SQL with CREATE USER, CREATE ROLE, GRANT, row policies, settings profiles, and quotas.

An operator on Fibric reads the tables its user may SELECT and proposes inserts and mutations for your approval, each with a receipt.

This is a reference listing. It documents what Fibric would read from ClickHouse and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Query results over HTTP in any FORMAT the server supports, with X-ClickHouse-Summary reporting read_rows, read_bytes, result_rows, and elapsed_ns
  • Rows from MergeTree tables the user may SELECT, restricted by row policies where you define them
  • Mutation progress from system.mutations, and parts, merges, and query history from other system tables
  • Sessions kept across requests with the session_id parameter, expiring after 60 seconds of inactivity by default
  • Organization, service, and API key records from the ClickHouse Cloud API at https://api.clickhouse.cloud/v1

Proposed actions

  • Target capability: propose an INSERT of rows into a named table over HTTP POST, sent once after approval
  • Target capability: propose ALTER TABLE ... UPDATE or DELETE, shown as the mutation it becomes, since it cannot be rolled back once submitted
  • Target capability: propose a service change through the ClickHouse Cloud API with an admin-role key

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Serve the operator's questions from event tables

    Run aggregate queries over MergeTree event tables through HTTP and return the rows behind each figure with the X-ClickHouse-Summary read counts.

    With Operations Analyst, Metric Reconciliation

  • Spot a metric that drifts

    Query the same window each hour, compare with the prior run, and raise a notice when a series leaves its usual band.

    With KPI Drift, Anomaly Notice

  • Watch merges and mutations that lag

    Read system.mutations and the parts tables and flag a table whose mutations stay unfinished or whose part count climbs.

    With Integration Health, Storage Growth

Requirements

  • A ClickHouse server reachable on port 8123 or 8443 for HTTP, or 9000 or 9440 for the native protocol
  • A user created with access_management enabled and granted SELECT on the databases and tables to read
  • INSERT and ALTER grants on any table where writes or mutations may be proposed
  • For ClickHouse Cloud management, an API key with the developer role for reads or the admin role for changes
Authentication
A ClickHouse user and password sent as HTTP Basic Authentication or the X-ClickHouse-User and X-ClickHouse-Key headers, with grants set by SQL; the ClickHouse Cloud API uses a Key ID and Key secret over HTTP Basic Authentication.

Limits

  • Mutations rewrite whole data parts asynchronously and cannot be rolled back after submission; KILL MUTATION only stops one that is stuck
  • Each ClickHouse Cloud API key allows 10 requests per 10-second window, and an organization holds at most 100 keys
  • A query is bounded by max_execution_time, max_memory_usage, max_result_rows, and max_result_bytes, which throw or break on overflow
  • readonly at 1 or 2 blocks INSERT, DELETE, UPDATE, and DDL on persistent tables; GET requests are readonly by default

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request ClickHouse ↗

Questions and answers

Is an HTTP GET request safe to run?
ClickHouse treats GET requests as readonly, setting readonly to 1 unless a stricter value applies, so only SELECT-style queries and session changes run. Writes need POST with a user granted INSERT or ALTER.
What happens when I propose an UPDATE or DELETE?
On MergeTree tables, ALTER TABLE ... UPDATE and DELETE are mutations. The statement returns once the entry is recorded, the rewrite of whole data parts proceeds in the background, and progress shows in system.mutations. There is no rollback after submission.
Which ports and protocols does the connector use?
The HTTP interface on 8123, or 8443 for HTTPS, and the native protocol on 9000, or 9440 with TLS. ClickHouse also emulates MySQL on 9004 and PostgreSQL on 9005. The Cloud API is separate, at https://api.clickhouse.cloud/v1 over HTTP Basic Authentication.
Ask about ClickHouse

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with ClickHouse through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy