Connecting Apache Superset to ClickHouse over HTTP(S) with clickhouse-connect
The supported way to connect a self-hosted Apache Superset to a self-hosted ClickHouse cluster is the clickhouse-connect Python driver over HTTP(S), installed into the same Python environment that runs Superset with pip install clickhouse-connect. The driver is provided by ClickHouse, and the ClickHouse guide for Superset is the reference to follow for the connection string format. Treat the Superset host as a client of the cluster: it needs network reachability to the ClickHouse HTTP(S) port and nothing else from the data layer.
Superset holds dashboards, charts, saved queries, users, roles and connection definitions in its metadata database, which is PostgreSQL or MySQL in production. The analytical data stays in ClickHouse, so a Superset upgrade, rebuild or restore does not move or copy event data, and a ClickHouse outage does not damage Superset's own metadata. Both products are licensed under the Apache License 2.0 (Apache-2.0), and Superset has no paid edition, so the license cost is zero and your costs come from the infrastructure, the people who run it and any partner work you commission. Confirm the exact driver version your Superset release expects against the ClickHouse guide and the Superset release notes before you pin it.
Before you build dashboards, decide which ClickHouse user Superset will authenticate as. Create a dedicated, read-only database user with access only to the databases Superset needs, and restrict the default user, which starts with all permissions. Confirm with your ClickHouse administrators how users, roles and settings profiles will be managed, because that decision determines how easily you can later restrict query limits and rotate credentials. Also confirm that the HTTP(S) endpoint uses TLS in your environment, since the credentials travel over that connection.
What you need in place before connecting Superset to ClickHouse
Four components have to be settled before the connection works: the Superset release, its metadata database, the ClickHouse endpoint and the network path between them. Each card below names one of those decisions and the check that confirms it.
Confirm the Superset release line
Superset 6.1.0 was published on May 13, 2026, and a 7.0.0 release candidate is listed as a pre-release dated October 16, 2026. Confirm with your team which line you will install and pin that exact version, because a release candidate is not a stable target for production. Read the upgrade notes for the chosen line before the first build, since breaking changes are listed per version.
Pick a supported metadata database
Superset stores dashboards, charts and users in a metadata database. Superset is tested with PostgreSQL 10 to 17 and MySQL 5.7 and 8.x, and the SQLite default is not recommended for production. Choose one of these, confirm the version against the configuration documentation, and plan its backups before the first dashboard is saved.
Choose a ClickHouse version on the security list
Target a ClickHouse line that appears in the current security policy as supported with security updates, such as 26.9, 26.8, 26.7 or 26.3, and check whether your team wants the stable or LTS track. Versions outside that list receive no security updates. Record the chosen line in your change record so that Superset and ClickHouse upgrades are planned against the same window.
Expose ClickHouse over HTTP(S) with TLS
Superset reaches ClickHouse through the HTTP(S) interface using the clickhouse-connect driver, not the native TCP port. Decide which port serves HTTPS, issue a certificate whose names match the hostname Superset will use, and make sure the certificate chain is trusted by the Superset host. Confirm that the driver is configured to verify the certificate rather than skip verification.
Generate a unique Superset SECRET_KEY
Superset will not start without a user-specified SECRET_KEY, a requirement added in version 2.1.0. Generate a long random value, store it in your secrets manager, and set it identically on every web and worker node. Document how it will be rotated, since Superset supports PREVIOUS_SECRET_KEY for that purpose, and test the rotation in staging before production.
Map the network path from workers
The connection is made by Superset processes, so the path must run from the Superset web and Celery worker hosts to the ClickHouse HTTP(S) endpoint, not from an analyst laptop. Check routing, DNS, firewall rules and any load balancer between the two. If alerts, reports or async queries run on workers, test the path from those hosts as well, because they may sit in a different subnet.
Configuring the driver, the database connection and the first dashboard
This sequence installs the ClickHouse driver into Superset, gives Superset a read-only ClickHouse identity, connects the two over HTTP(S), and proves the path works with one bounded chart. Each step ends with a check you can repeat before any wider rollout.
Install the clickhouse-connect driver
The Superset platform team installs the clickhouse-connect Python driver into the same environment that runs Superset, either by adding it to the Superset image build or by installing it into the virtual environment with pip install clickhouse-connect. Superset needs this driver to speak HTTP(S) to ClickHouse, so it must live in every Superset web and worker container or host that will run queries. Done means the driver imports cleanly inside the running Superset environment, and the Superset version in use is confirmed against the release notes before you pin anything.
Create a read-only ClickHouse user
A ClickHouse administrator creates a dedicated user for Superset with access control statements, assigns it a role that grants SELECT only on the named databases and tables, and sets a restrictive settings profile if your standards require one. Do not reuse the default user, which starts with all permissions, and do not give Superset write or DDL rights for dashboards. Done means a test login as this user can read the approved tables and is refused on an insert or a table outside the grant, which you confirm with a deliberately denied statement.
Confirm the HTTP(S) endpoint and credentials
The platform team records the ClickHouse host name, the HTTP or HTTPS port your cluster exposes, and the credentials for the new user, and confirms with the cluster owner that the Superset hosts can reach that port through your network controls. Use HTTPS where your security standards require encrypted transport, and confirm the certificate chain is trusted by the Superset runtime. Done means a simple connectivity check from a Superset host returns a response from ClickHouse over the chosen protocol.
Add the ClickHouse database in Superset
A Superset administrator opens the database connections screen, selects ClickHouse as the engine, and enters the host, the HTTP(S) port, the read-only username and its password, and the default database or schema to expose. Store the password through your secrets handling rather than pasting it into shared notes, and limit which Superset roles can edit this connection. Done means the connection record saves without error and appears in the list of available databases.
Test the connection and inspect ClickHouse logs
Use the connection test in Superset, then run a small query such as selecting the current user and the server version from the Superset SQL editor. Open the ClickHouse system query log on the cluster and search for the query text and the read-only user name to confirm that the request arrived under the expected identity. Done means the test succeeds, the query appears in system.query_log under the Superset user, and the logged user is not the default account.
Build a first chart on a bounded time range
An analyst builds a simple chart on one approved table, such as a count of events per hour, and sets a fixed time filter covering a short, deliberate window instead of the full history. Confirm that the table's sorting key and partitioning support that filter, and ask the data owner which time column is indexed. Done means the chart renders, the generated SQL includes the time predicate, and the query duration and rows read appear reasonable in the system query log.
Review the first dashboard before sharing
The platform and data owners review the chart SQL, the time range default, and the query log entries together, then decide whether the dashboard can go to a wider audience. Adjust the dataset definition or add a narrower default filter if reads cover more data than the question needs. Done means a short written sign-off records the approved table grants, the default time window, and the list of users allowed to open the dashboard.
Choosing the right connection pattern for your environment
A single Superset instance connected to one ClickHouse node is the simplest pattern and the one the ClickHouse Superset guide describes first. Superset connects over HTTP(S) through the clickhouse-connect driver, so most of the work sits in the connection itself and the account it uses. Install the driver into the same Python environment as Superset, then add ClickHouse as a database using the connection details from the guide.
- Protocol and port: Use HTTPS where the node presents a certificate, and use the HTTP or HTTPS port your cluster owner has opened. Confirm the port with that owner before copying any value from an example.
- Dedicated read-only user: Create a user with read-only grants for the dashboard tables. The default user starts with all permissions, so restrict it or keep it off the Superset connection.
- Database scope: Limit the connection to the database that holds the dashboard tables, and check which databases the user can list from SQL Lab.
- Test before saving: Run a small query from the Superset host, then compare the result with the same query run in a ClickHouse client.
- No failover target: If the node stops, every dashboard stops with it. Agree on a maintenance window and tell dashboard owners before restarts.
Check that the Superset host can reach the node on the agreed port, that the Superset user is read-only, and that a test query returns the expected result.
When many people open dashboards, Superset usually runs as several instances behind a load balancer, pointed at a replicated ClickHouse cluster. Replicated tables use ReplicatedMergeTree and ClickHouse Keeper, and a recovered replica syncs missing data from a healthy replica without manual steps. That improves availability, but the connection layer now has to handle replicas that may be at slightly different points in their data.
- Load balancer targets: Point the load balancer at the HTTP(S) endpoints of the ClickHouse nodes, and configure health checks so a node that is down or unresponsive leaves the pool. Confirm the health check method with your network team.
- Shared Superset metadata: Every instance must use the same PostgreSQL or MySQL metadata database. The architecture documentation tests those two, and the SQLite default is not recommended for production.
- Shared secret and workers: Set the same
SECRET_KEYon each instance. If you run alerts, async queries or thumbnails, point all instances at the same caching layer and worker set. - Replica lag: A dashboard query can land on a replica that has not yet received the newest inserts. Ask data owners whether panels can tolerate that delay, and label near-real-time charts accordingly.
- Failover test: Stop one ClickHouse node during a dashboard refresh, confirm the failed queries and load balancer behavior are acceptable, and confirm the node rejoins once restarted.
Confirm that health checks remove a stopped node, that two Superset instances return the same chart for the same query, and that all instances point to one metadata database.
In an air-gapped or restricted network, the Superset host cannot reach public package indexes, so the driver and Superset arrive through an internal mirror. TLS certificates for the ClickHouse endpoints come from an internal certificate authority. Plan both before the build, because the first failures in these environments are usually a package install or a certificate validation error.
- Package mirror: Mirror
clickhouse-connectand Apache Superset, with their dependencies, into your internal Python package repository. Pin the versions you have tested. - Internal CA trust: Add the internal root and intermediate certificates to the trust store used by the Superset process, then confirm the driver validates the cluster certificate. Check the certificate settings in the driver documentation for your version.
- Authentication choice: ClickHouse supports LDAP, Kerberos, SSL X.509 certificates, an HTTP authenticator and JWT as external authenticators. Choose the method your directory already operates, and confirm it works for the Superset service account.
- Access scope: Keep the ClickHouse user read-only and review the access control documentation for roles, row policies and quotas before exposing sensitive tables.
- Updates through the mirror: Superset and driver upgrades must also come through the mirror. Read the changelog and UPDATING.md, then test in staging first.
Confirm that the Superset host installs the pinned packages with no outbound access, that the connection validates the internal certificate, and that dashboard queries run under the read-only account.
Mapping Superset roles, ClickHouse users and data access
This table maps each access decision to the system that enforces it: Superset roles control what users see in the application, while ClickHouse users, roles, grants and row policies control what queries can actually read. Read it top to bottom to decide where each tenant, region or team boundary must be enforced. The main takeaway is that Superset permissions alone do not restrict data inside ClickHouse.
| Access decision | Enforced by | Where it fails | What to confirm |
|---|---|---|---|
| Which Superset roles can open a database connection | Superset roles and dataset permissions | Users with broad Superset roles can still query any table their ClickHouse user can read | Which Superset roles hold database and SQL Lab permissions in your instance |
| Which ClickHouse tables the BI service account can read | ClickHouse user grants on databases and tables, through roles | Grants left at the default user or on whole databases expose more tables than dashboards use | Grant lists for the Superset service user, reviewed after each new dataset |
| Tenant or region filtering of rows | ClickHouse row policies attached to the Superset service user or its roles | Filters added only as Superset chart filters can be removed by a user writing SQL Lab queries | Row policy definitions per tenant and region, and tests run as the service user |
| Which LDAP or OAuth groups get which Superset role | Superset AUTH_ROLES_MAPPING in the Superset configuration | Group mapping controls Superset screens only, not the ClickHouse account used for queries | Group names in your identity provider and the Superset roles each maps to |
| Shared or per-user ClickHouse identity for queries | Superset database connection credentials, or ClickHouse external authenticators for per-user identity | A single shared service user removes per-user audit trails in ClickHouse query logs | Whether analysts need individual ClickHouse accounts and how query logs will attribute them |
| Query resource limits per session or user | ClickHouse settings profiles and quotas | Without limits, one heavy dashboard can consume cluster resources shared with other workloads | Profile values for the Superset user and who approves changes |
| Default account exposure | ClickHouse access control, with the default user restricted | The default user starts with all permissions, so a dashboard connection to it grants full access | That the default user is restricted and the Superset connection never uses it |
Locking down the Superset to ClickHouse path
The Superset to ClickHouse path crosses three trust boundaries: the Superset metadata and secrets, the HTTP(S) connection, and the ClickHouse user that runs every dashboard query. The controls below close each boundary, and each one has a decision to make before the first dashboard goes live.
Dedicated read-only ClickHouse user
Create a separate ClickHouse user for Superset with SELECT grants only on the databases and tables its dashboards need, and do not reuse the default user. ClickHouse documents that the default user starts with all permissions, so leaving it in place for dashboards gives every chart full write and administrative reach. Check that the Superset connection string uses this user and that a test write from it is refused.
TLS on the HTTP(S) endpoint
Serve the ClickHouse HTTPS interface with X.509 certificates so that credentials and result sets are not sent in clear text between Superset workers and the cluster. Confirm which certificate authority Superset's host trusts, how certificates are renewed, and whether the clickhouse-connect client verifies the server name. Treat the certificate and key files as secrets with restricted file permissions.
External authentication where it already exists
If the organization already runs LDAP, Kerberos, JWT or an HTTP authentication service, ClickHouse can accept those identities instead of local passwords for analyst access. Decide which path Superset's service account uses, since a shared service identity still needs the read-only grants above. Confirm each option against your own directory and token issuer before relying on it, because the setup differs by method.
Quotas and settings profiles for dashboards
Attach a settings profile to the Superset user that caps query memory, execution time and row reads, and add a quota that limits how many queries and how much data the account may consume in a set interval. Dashboards refresh on schedules and can fan out many queries at once, so an uncapped account can slow the cluster for other users. Ask your ClickHouse administrator which limits match the largest chart you plan to publish.
Superset SECRET_KEY and rotation
Superset will not start without a SECRET_KEY that you set, and it signs session data and encrypts stored database credentials. Keep the key in a secrets manager rather than in a file in the repository, and restrict who can read the configuration. When the key changes, set PREVIOUS_SECRET_KEY so existing sessions and stored values keep working during the rotation, then remove the old value once rotation completes.
Dashboard query patterns that keep ClickHouse load predictable
Dashboards put load on a ClickHouse cluster in ways that ad hoc analysis does not. A single dashboard can hold a dozen charts, each issuing its own query, and when those charts refresh together after a page load or on a shared timer, the cluster sees a burst of scans against the same large event table. Unbounded filters make it worse. A chart that omits a time range forces ClickHouse to read every partition it has, and users who build their own charts in Superset's explore view can introduce expensive group-bys or wide joins without anyone reviewing them. Start by deciding which dashboards are allowed to query raw event tables at all, and which should read only from summary tables.
Three controls reduce this load. First, make every time-based chart take a bounded range by default, and align that range with the partition key of the source table so ClickHouse can prune partitions instead of scanning them. Second, for charts that run the same aggregation on every refresh, build a summary table with a materialized view and point the chart at it, so the dashboard reads a small table instead of the raw stream. In Superset, cache chart results for a period that matches how fresh the business needs the numbers to be, and check how the cache behaves for filters that change per user. Third, agree refresh intervals with the platform team before publishing dashboards, and set them per dashboard rather than leaving each chart on its own schedule.
Treat all of these settings as hypotheses until you have measured them. Ask the platform team to enable query logging and review the cost of each dashboard query in your own environment, including rows read, memory and run time, before and after each change. Confirm the exact cache and refresh options in your Superset version's documentation, since they vary between releases. A dashboard that looks cheap in a test with a few users can behave very differently when fifty analysts open it at the start of a shift.
Testing the integration before users see dashboards
How should I test a Superset to ClickHouse connection before rolling it out?
Test it in a staging Superset that points at a staging ClickHouse cluster loaded with a copy of representative data, not an empty database. Connect with the same clickhouse-connect driver and the same read-only user you plan to use in production, then open each dataset, run each chart's query, and confirm that results match what the source system reports for the same filters. Keep the staging copy close to production in table layout, row volume and partitioning, because a query that is fast on a small sample can behave very differently on the full dataset. Record which dashboards passed so the production sign-off has a clear list to check against.
How do I confirm the Superset database user is actually read-only?
Log in through Superset's SQL Lab as that user and attempt a harmless write, such as an INSERT into a scratch table or a CREATE TABLE, and confirm ClickHouse rejects it with a permission error. Then check that a read query against an allowed table succeeds, so you know the grant works in both directions. Do the same test with a row policy in place if you use one, because a user can read rows they should not see if the policy is missing. Keep the test result as evidence. The access control documentation recommends managing users and roles through SQL and restricting the default user, which starts with all permissions, so confirm the default user is locked down as well.
How do I check which queries Superset sends to ClickHouse?
Filter the ClickHouse query log by the user name of the Superset account and review the statements it runs. Look for full table scans over large tables, queries without time filters, and repeated identical queries that come from the same chart refreshing. Compare the query text with what each chart is meant to show, because Superset builds SQL from chart settings and a small change in a metric or filter can turn a bounded query into an unbounded one. Confirm the query log is enabled on the staging cluster before the test starts, and confirm who can read it, since query text can contain sensitive values.
How do I load-test a dashboard with realistic concurrency?
Build a test that opens the same dashboards that analysts will use, with the same filters, at a number of simultaneous sessions that reflects your expected peak. Measure the time each chart takes to return and the load on the ClickHouse servers, including memory, CPU and any queries that queue or fail. The result should tell you which charts are expensive and whether they need a materialized view, a projection, a pre-aggregated table or a default time range. Agree the target concurrency and acceptable response times with the business owners before the test, because the numbers you choose drive the sizing decision. Repeat the test after any schema or dashboard change.
What does a Superset upgrade rehearsal involve?
Rehearse the upgrade on a staging copy of your Superset deployment with a copy of its metadata database, following the upgrade documentation. The core steps are to back up the metadata database, install the new version, run superset db upgrade to apply schema migrations, run superset init to refresh roles and permissions, and then restart the web and worker processes. Before you start, read UPDATING.md in the Superset repository for breaking changes between your current and target versions, since some changes affect configuration or dependent packages. Time the rehearsal and note every manual step, so the production window has a tested runbook and a rollback path that restores the metadata database backup.
Should I test the ClickHouse driver version separately from Superset?
Yes. Superset and the clickhouse-connect driver are installed separately, so a driver update can change query behavior or connection handling even when Superset itself has not changed. Pin the driver version in your build, test it in staging with the same dashboards and queries, and record the versions of Superset, the driver and ClickHouse together in your change record. Check the ClickHouse production guidance on version choice before you move the server, since the server and driver should both be on versions your team has tested together. Ask your vendor or internal platform owner which combinations they support.
Can DeployOpen run this verification for our team?
DeployOpen can plan and run this verification as part of an implementation or as a separate fixed-scope piece of work, with the staging environment, test data, read-only user checks, query log review, load test scope and upgrade rehearsal agreed in writing before work starts. The effort depends on how many dashboards you have, how large the dataset is, how much of the environment is already automated and how many versions are in scope. Ask for a quote built from that written scope, and ask what each deliverable looks like, including the test results, the runbook and any changes recommended. Your own team should still own the business sign-off on dashboard accuracy.
Common failures when Superset cannot reach or query ClickHouse
This table pairs each common failure with its likely causes and the first checks to run, so teams can narrow down where a Superset to ClickHouse problem starts. Use it as a triage list, then confirm exact error text with the clickhouse-connect driver, Superset logs and ClickHouse server logs in your environment. The main takeaway is that most failures sit in the network path, the user grants, the cache settings or the worker setup, not in the dashboard itself.
| Failure | Likely causes | First checks and fixes |
|---|---|---|
| Connection refused or TLS errors | Wrong HTTP(S) port, TLS not enabled on the endpoint, certificate chain not trusted by the Superset host, or a firewall between the Superset and ClickHouse hosts | Confirm the HTTP or HTTPS port the cluster exposes, test reachability from the Superset container or host, and check that the CA bundle used by the driver trusts the server certificate |
| Authentication failures with external authenticators | LDAP, Kerberos, JWT or HTTP authenticator configured on the server but not matched by the credentials Superset sends, or an expired token or ticket | Check which authenticator the target user uses, verify the connection string user matches the directory entry, and review ClickHouse server logs for the rejected login |
| Permission denied on a dataset | The read-only user lacks SELECT on the database or table, a row policy hides rows, or the default user was restricted and the new user has no roles | Grant SELECT to a dedicated role on the required objects only, test the same query with that user in clickhouse-client, and review row policies that apply to it |
| Dashboards timing out | Charts scan large unfiltered tables, time ranges are unbounded, too many charts load at once, or the query lacks an ordering key that matches its filters | Require a time filter on large datasets, point charts at aggregated or materialized tables, limit concurrent chart loads, and set query limits for the Superset user |
| Charts showing stale results | Superset's caching layer serves cached query results beyond the expected refresh, or cache timeouts are set too long for the data freshness the business expects | Review cache timeout settings for each dataset, clear cached entries when a dataset is rebuilt, and confirm the displayed data timestamp against a direct ClickHouse query |
| Async queries or alerts failing | The Celery worker or beat process is not running, Redis is missing or unreachable, or the caching layer is not configured as the architecture requires | Confirm the worker and beat processes start, verify the Redis connection settings from the worker container, and check worker logs for task errors before changing dashboards |
| Metadata or startup errors after configuration changes | SECRET_KEY not set or changed without PREVIOUS_SECRET_KEY, or the metadata database version falls outside the supported range | Set a user-specified SECRET_KEY, use PREVIOUS_SECRET_KEY during rotation, and confirm the metadata database version against the Superset configuration documentation |
Questions buyers ask about connecting Superset to ClickHouse
Is Apache Superset paid software that I need to license?
No. Apache Superset is an Apache Software Foundation project released under the Apache License 2.0, and the project has no paid edition. Your costs come from the infrastructure you run it on, the people who build and operate it, and any support or retainer you choose. The ClickHouse driver is also provided by ClickHouse and installed with pip install clickhouse-connect. Confirm the licence terms of any optional components you add, such as a managed database or a commercial authentication provider, since those are separate decisions.
What drives the cost and effort of connecting Superset to ClickHouse?
Effort grows with the number of data sources, the identity integration, the network and certificate work, and the number of dashboards that must perform under load. A single cluster with one read-only role and a handful of dashboards is a small scope. Adding LDAP or OAuth2 group mapping, TLS between Superset and the cluster, private network paths, and load testing for many concurrent dashboards each add work. Ask any partner for a quote that lists each data source, each identity integration, each dashboard group, and whether load testing and a staging environment are included.
Can my team do this in-house using the official documentation?
Often yes, if you have engineers who already run Superset and ClickHouse. The ClickHouse documentation covers the Superset connection, and the Superset documentation covers installation, configuration and upgrades. The work becomes harder when you need a production-grade metadata database, a caching layer and workers for alerts and async queries, group-based access, and restricted ClickHouse users. Decide early whether your team has time to test each step in staging and to keep it current through upgrades.
How long does a Superset to ClickHouse connection project take?
Duration depends on the scope you agree in writing, so DeployOpen gives timelines only once that scope is defined. The main variables are the number of ClickHouse databases and tables exposed, how many identity groups map to Superset roles, whether TLS and private networking must be designed, and how many dashboards need to be tested for predictable load. Ask for a timeline that is tied to named deliverables, with staging validation listed as a separate step.
What do I need to provide before work starts?
Prepare access to the ClickHouse cluster or a staging copy with representative data, and a named owner for each dataset Superset will expose. Provide your identity provider details if single sign-on or group mapping is in scope, plus the network paths and certificate authority used internally. A staging Superset environment is needed to test changes before production. Also identify who approves new read-only users and who answers questions about metrics and dashboard definitions.
Should Superset connect to ClickHouse with the default user?
No. The ClickHouse access control documentation recommends restricting the default user, which starts with all permissions. Create a dedicated Superset user with read-only grants on the approved databases and tables, and use roles so access can be reviewed. Restricting the user limits the damage from a misconfigured chart or an injected query, and it also makes it clear which data each dashboard can reach. Confirm which row policies and quotas your data owners require before go-live.
How do I keep dashboard load on the ClickHouse cluster predictable?
Limit what each dashboard can ask the cluster to do. Use aggregated tables or materialized views for common charts, set query limits and quotas for the Superset user, and avoid charts that scan raw event tables on every refresh. Test dashboards in staging with realistic concurrency before publishing them. Plan how often dashboards refresh and whether alerts and async queries need the Superset caching layer and Celery workers, since those add components to operate and patch.
How DeployOpen scopes a Superset to ClickHouse integration
DeployOpen plans and implements this integration inside your own infrastructure, whether that is your cloud accounts, data centers or an air-gapped network. The work covers the Superset deployment that reads from ClickHouse, the clickhouse-connect driver installed in the Superset environment, the HTTP(S) connection to the cluster, read-only database users with a restricted role, and the dashboard query patterns that keep load predictable. Most engagements are fixed-scope, so the deliverables and timelines are agreed in writing before any work starts. A written scope for this integration usually names the Superset and ClickHouse versions in use, the hosting model for each, the metadata database, the networks and certificates involved, the user groups and the datasets each group may query, and the staging environment used for testing.
The scope also needs to say who owns each decision that affects cost and risk. Examples include whether Superset needs the caching layer and Celery workers for alerts, reports or async queries, whether authentication is delegated to an existing LDAP or OAuth2 provider with group-to-role mapping, and which dashboards must be tested against representative data before go-live. Ask the vendor or partner to state which items are included, which are assumed to be provided by your team, and how changes after sign-off are handled. Confirm these points against your own environment before the scope is signed, because they determine the effort more than the driver itself does.
Ongoing support, upgrades and continuous testing are available as retainers, which suits teams that expect Superset and ClickHouse to change after the first release. DeployOpen does not publish a price list. A quote follows from the written scope, so the most useful request is a scope document that lists components, environments, user groups, integrations and acceptance tests. Compare quotes on what each one includes, what is one-time and what recurs, and who carries the work for upgrades and restore tests.
How DeployOpen delivers and supports your Superset and ClickHouse integration
DeployOpen plans, builds, documents and supports the Superset and ClickHouse connection inside your own infrastructure, from the network path and driver setup to read-only database users and dashboard query patterns. Engagements are fixed-scope, with scope and deliverables agreed in writing before work starts, and ongoing support is available as a retainer.
How we scope
- Written scope covers which ClickHouse databases and tables Superset may query and which dashboards are in scope.
- We confirm the Superset and ClickHouse versions, the HTTP(S) endpoints and the network path between the two.
- Scope names the read-only database roles, row policies and query limits that each dashboard group will use.
How we build
- We install clickhouse-connect in the Superset environment and configure the HTTP(S) connection with TLS verification.
- We create dedicated read-only ClickHouse users and restrict the default user before any dashboard connects.
- We test dashboard queries against a pre-production cluster with representative data to check predictable load.
How we hand over
- You receive documented connection settings, user and role definitions, and the query patterns agreed for dashboards.
- We provide a runbook covering Superset metadata database backups and the upgrade steps in the Superset upgrade documentation.
- Handover includes a walkthrough with your team so they can add charts and datasets within the agreed model.
How we support
- Ongoing support is available as a retainer for Superset and ClickHouse upgrades, access changes and performance reviews.
- We review changelogs and breaking-change notes before each planned upgrade of either product.
- Continuous security testing and documentation updates can be added to the retainer where your team needs them.
