Connecting Tableau to ClickHouse with the official connector
Analysts who want Tableau dashboards over a self-hosted ClickHouse cluster have one supported starting point: the official ClickHouse Tableau connector listed on Tableau Exchange. It is built on the ClickHouse JDBC driver and exposes ClickHouse databases and tables as Tableau data sources, so the work is less about writing custom SQL bridges and more about deciding how the connection authenticates, which network path it takes, and which tables analysts are allowed to see. The vendor's setup walkthrough is the natural next read: Connecting Tableau to ClickHouse. Confirm the connector version and the Tableau Desktop and Tableau Server or Cloud versions it supports against that page before you plan the rollout, since compatibility is set by the connector release rather than by ClickHouse itself.
This page covers the parts a platform team has to settle around that connector: installing the JDBC driver and connector on the machines where Tableau runs, choosing between live and extract connections, and deciding how a Tableau Server or Tableau Cloud publishing path reaches a cluster that sits inside your network. It also covers the points where the connection choice changes load on ClickHouse, which matters for shared clusters that also serve ingestion. It does not replace access design. The connector only passes along whatever user, password and network reach you give it, so the ClickHouse users, roles, row policies and quotas behind the Tableau login decide what analysts can read. Treat the connector as the last step of your access model, not the first.
Prerequisites for a Tableau connection to ClickHouse
A Tableau connection is only as stable as the layers beneath it. The cards below cover the cluster, the Tableau host, the driver pairing, the network path and the database account that analysts will use. Settle each one before the connector is installed, because most failed first connections trace back to one of them.
A cluster your team operates
The connector points at a ClickHouse cluster you already run, not at a sandbox that will be rebuilt later. Confirm who owns patching, replica health and restores for that cluster, since analyst dashboards will fail whenever it is down. Check which release line the cluster runs, and plan upgrades against the connector's supported versions. Analysts should query a cluster that already has its production tables loaded and tested.
A Tableau edition and host
Confirm that your Tableau edition and deployment model can install and run the ClickHouse connector. Desktop users need the connector installed on their own machines, while Tableau Server or Cloud needs it deployed on the server side and any on-premises access routed through a gateway. Record the Tableau version and operating system for each host that will connect, because connector support varies by release. Check the official connector guide before you commit to a deployment model.
A matching JDBC driver version
The Tableau connector is built on the ClickHouse JDBC driver, so the driver version has to match what the connector expects. A mismatch shows up as connection errors, missing tables or unexpected type mapping in Tableau. Pin the driver and connector versions together in your change records, and retest both whenever either one changes. Confirm the pairing against the official guide and against the ClickHouse release line your cluster runs.
Network paths to HTTP ports
Each Tableau host, or the gateway that serves it, needs a route to the ClickHouse HTTP interface, typically on the HTTPS port your cluster exposes. Ask the network team to document the source addresses, firewall rules and any load balancer in front of the cluster. Tableau connections should reach a load balancer or a stable endpoint rather than a single replica, so one node failure does not break every dashboard. Test the path from each host type before analysts are onboarded.
TLS certificates the clients trust
Tableau hosts must trust the certificate chain presented by the ClickHouse HTTPS endpoint, or the JDBC connection will fail or be disabled by workarounds. Confirm that the certificate covers the hostname analysts will type, that its chain is issued by an authority your Tableau machines or servers trust, and that you have a renewal date on record. Avoid disabling certificate verification to get a connection working. Plan for certificate rotation as part of normal cluster operations.
A dedicated read-only user
Create a separate ClickHouse user for Tableau with read-only permissions on the databases and tables it needs, and do not reuse the default user or an administrator account. ClickHouse access control supports users, roles, row policies and settings profiles, so you can limit reads to approved data and set query limits. Restrict the default user, which starts with all permissions, before connecting any BI tool. Document who owns this account and how its password or certificate is rotated.
Configuring the Tableau connector step by step
This sequence takes a self-hosted ClickHouse cluster from a supported version to a Tableau data source that analysts can query under a read-only account. Each step ends with a check you can run before moving on.
Confirm the cluster version and support status
Before any Tableau work, confirm which ClickHouse version your cluster runs and whether the ClickHouse security policy lists it as supported with security updates. The policy currently lists versions 26.9, 26.8, 26.7 and 26.3 as supported, and all others as unsupported. Ask your platform team to record the exact server version from a query against the cluster, and confirm that the connector and JDBC driver versions you plan to install are compatible with it in the official Tableau connector documentation. Done means you have a written version number and a support status for it.
Create a read-only analyst user and role
Create a dedicated role that grants only SELECT on the databases and tables analysts need, then create a named user for the Tableau connection and assign that role. Do not reuse the default user or an administrator account, because the access control documentation notes that the default user starts with all permissions and recommends restricting it. Where the data is sensitive, add row policies or a settings profile with limits on the account. Done means a test query run as that user succeeds on an allowed table and fails on a table outside the grant.
Install the JDBC driver and the Tableau connector
Install the ClickHouse JDBC driver on each Tableau Desktop machine and on Tableau Server or Tableau Cloud gateway hosts if you publish there, then install the official ClickHouse connector from Tableau Exchange. The connector is built on the ClickHouse JDBC driver, so the driver version must match what the connector documentation expects. Your desktop administrator usually owns this step. Done means the ClickHouse connector appears in Tableau's connector list and the driver loads without errors on a test machine.
Enter host, port, database and TLS settings
In Tableau, open the ClickHouse connector and enter the host name of the cluster endpoint your analysts should reach, the HTTP or HTTPS port your network team has opened, and the default database. Enable TLS and supply the CA certificate chain that your internal certificate authority issued for the endpoint, so the connection does not depend on disabling certificate checks. Confirm the port and protocol with your network team rather than assuming defaults. Done means the connection dialog accepts the settings without certificate warnings.
Test the connection and browse tables
Use the Test Connection button, then sign in with the read-only analyst account. After a successful test, open the database list and browse the tables the role allows, checking that tables outside the grant are not visible or cannot be opened. Run a simple count on one large table in Tableau and compare the result with a count query run directly against ClickHouse as the same user. Done means the test connection succeeds and the row counts match.
Choose live or extract and build the data source
Decide whether each data source should query ClickHouse live or load an extract. Live connections send each interaction to the cluster, so their load depends on dashboard design, filters and the size of the underlying tables. Extracts copy data into a Tableau file that refreshes on a schedule, which trades freshness for predictable cluster load. Choose the option per data source, select the tables or custom SQL, and apply filters that keep queries bounded. Done means the data source saves and a sample sheet returns the expected totals.
Publish and verify access from a second account
Publish the workbook or data source to Tableau Server or Tableau Cloud, store the database credentials in the publishing workflow rather than in a shared workbook, and confirm the embedded or saved credentials use the read-only account. Then open the published view as a different analyst who has the same role and check that the data and row counts match the earlier test. Done means the published view refreshes or loads with the same results, and the credentials in use are the read-only account.
Record the setup and review access periodically
Document the cluster version, driver and connector versions, role grants, network path and the refresh design for each data source, so the setup can be repeated after an upgrade. Read the changelog before upgrading ClickHouse, because the production FAQ notes that minor backward-incompatible changes can occur, and then repeat the connection and count checks against a pre-production cluster. Done means a runbook exists and the checks pass after the most recent change.
Live or extract: choosing the Tableau connection mode
A live connection sends every interaction in a Tableau view to ClickHouse as a query, so the answer reflects the data at the moment the user looks at it. This suits small result sets, operational views where stale numbers cause problems, and dashboards with few concurrent viewers. Because each filter change or drill-down reaches the cluster, the load lands on the ClickHouse replicas that serve the connection, and a wide dashboard with many marks can generate heavy concurrent work.
- Freshness: Users see rows as they are inserted, which matters for monitoring or near-real-time review.
- Query load: Every viewer interaction runs against the replicas, so load grows with concurrency and the number of visible sheets.
- Query design: Aggregations should run on sorted or pre-aggregated tables, since a live view over raw events scans far more data on each click.
- Network path: The connection depends on reachability from Tableau Desktop or Tableau Server to the cluster endpoint at all times.
- Operations: A slow or unavailable node is visible to users immediately, so replica health and query limits need to be in place first.
Before committing to live mode, confirm with your ClickHouse operators which replicas and quotas will serve analyst traffic and whether those limits hold at your peak viewer count.
An extract connection copies the data that a workbook needs into a Tableau extract file and serves dashboards from that file. ClickHouse is queried during refresh rather than during each interaction, which moves the load into a scheduled window and keeps interactive use off the cluster. Extracts suit heavy dashboards, repeated slicing across many filters, and data that changes on a predictable cycle. The trade-off is that users see data as of the last successful refresh, and the extract consumes storage and refresh capacity on the Tableau side.
- Refresh scheduling: Full and incremental refreshes need windows that avoid peak ingestion and replica maintenance on the cluster.
- Extract storage: Extract size grows with the rows and columns included, so filtering to needed fields and date ranges limits both disk use and refresh time.
- Interactive speed: Dashboards read the local extract, so repeated filtering does not repeat queries against ClickHouse.
- Failure behavior: A failed refresh leaves the previous extract in place, so teams need alerting on refresh failures to avoid silently stale numbers.
- Concurrency control: Scheduled refreshes that start together can create a burst of queries, so stagger them across workbooks.
Confirm the refresh schedule and extract size with your Tableau administrators, and check with your ClickHouse team that the planned refresh windows fit the cluster's maintenance calendar.
The cost of each mode lands in different places. On the ClickHouse side, cost is consumed as CPU, memory and I/O on replicas during query execution, and as concurrency pressure when many analysts run queries together. On the Tableau side, cost is the extract storage, the refresh compute and the server capacity that schedules and runs refreshes. Neither side is a fixed price, so the right mode depends on how many people use each dashboard and how often the underlying data changes.
- Query load on replicas: Live queries and refresh queries both consume replica resources, and live mode repeats that work on every interaction.
- Concurrency: Peak simultaneous users set the required headroom, which is often the constraint that decides between modes.
- Refresh windows: Extract refreshes concentrate load into set periods, which can collide with ingestion or merges if not scheduled.
- Tableau storage and compute: Extract files and the Tableau Server or Cloud capacity used for refreshes are recurring costs that grow with data volume.
- Licensing and staffing: Tableau licensing and the time your administrators and ClickHouse operators spend on scheduling are cost items to include in any quote or internal estimate.
Ask your implementation partner or internal team to model query volume and extract sizes from a sample of real dashboards before deciding which costs you can carry.
The right mode is easiest to choose by measurement, not by assumption. Build the same workbook twice, once live and once as an extract, against a copy of the data that matches production row counts, column types and partitioning. Run both with realistic user counts and filter patterns, and record query duration, cluster load, extract size and refresh time. A test that uses a small sample table can make both modes look faster than they will be at scale.
- Representative data: Use a table with production-like volume and the same sorting and partition design, since these determine scan cost.
- Concurrent load: Simulate the expected number of simultaneous viewers, including the busiest hour of the business day.
- Measurements: Capture query time per interaction, replica CPU and memory, extract file size and refresh duration.
- Freshness requirement: Document the maximum acceptable data age for each dashboard, since that requirement often settles the choice.
- Hybrid option: Some teams keep summary dashboards as extracts and detail views live, which is worth testing where both needs exist.
Record the results and the chosen mode for each dashboard, then review them after the first quarter of use, when real query patterns and data growth are visible.
How ClickHouse databases and tables appear in Tableau
The official ClickHouse Tableau connector exposes the databases and tables on your cluster as selectable data sources, so the first decision is scope. Analysts should connect to a database that holds reporting-ready tables rather than the whole server, because every table the connector can see becomes a candidate source in the Tableau data pane. Confirm which databases the connector will list for the account you provide, and confirm that system databases are hidden from analysts. Views and materialized view target tables are the usual candidates for reporting, while raw ingestion tables are often better left out of the default path. Record the list of approved sources as part of the rollout, so that the set analysts see is a deliberate choice rather than an accident of permissions.
Column types are where mismatches appear. ClickHouse has types with no direct equivalent in Tableau's data model, including wide integers, decimals with unusual precision, arrays, maps and nested structures, and Tableau may read these as strings, drop them or require a cast in a calculated field. Nullable columns need a check too, because ClickHouse stores NULL as a separate flag on a column, and a Nullable Date or numeric field can change how filters, averages and counts behave in a dashboard. Use a sample of real tables to compare the field types Tableau shows against your DDL, and ask the connector maintainer or review the connector documentation for the current type mapping before you promise analysts specific fields. Document the result as a table of column types and the expected Tableau type, and rerun the check after each ClickHouse or connector upgrade.
Plan for the fields you cannot map cleanly. The usual fix is a reporting view that casts unsupported or ambiguous types into plain types (for example, String, Int64, Float64 or Date) and flattens arrays or maps into scalar columns, so dashboards depend on a stable contract rather than raw storage types. Keep these views in the same database and owned by the team that owns the schema, so a change to a source table does not silently change what analysts see. Ask your data team to name the owner of each reporting view, and treat any type change in a view as a change that needs a dashboard check before release.
Mapping ClickHouse roles and objects to Tableau access
This table maps ClickHouse users, roles, row policies and settings profiles to the Tableau users, workbook owners and published data sources that depend on them. Read each row as a control to set in ClickHouse, with the Tableau side explained so the two layers line up. The main takeaway is that Tableau filters are a presentation layer, so access rules must be enforced in ClickHouse.
| Object | Tableau side | ClickHouse side | Check before publishing |
|---|---|---|---|
| Default user | Not used by analysts; connections should never log in as default | Starts with all permissions; restrict or disable it and keep it off the Tableau connection path | Confirm no published data source or saved credential uses default |
| Analyst role | Each published data source connects with credentials tied to one analyst group | Role grants SELECT only on chosen databases and tables, not the whole cluster | Test that a sample analyst account cannot list or read tables outside its databases |
| Service user for Tableau | Holds the credentials embedded or stored for published data sources | Dedicated read-only user with a settings profile limiting query resources | Confirm the user cannot create, alter or drop objects |
| Row policy | Tableau user filters cannot replace it; a filter in a workbook only narrows what the view shows | Row policy applies to every query from that user, including custom SQL and extracts built from it | Run the same query through Tableau and the ClickHouse client and compare row counts |
| Workbook owner | Owns workbook content and publishing rights, not database rights | Owns no ClickHouse account; access comes from the role the data source uses | Confirm owners cannot edit the embedded connection to a more privileged user |
| Settings profile | Controls how long a dashboard query may run or how much memory it may use | Assigned to the Tableau service user to cap resource use per query | Ask the cluster team which limits apply and test a heavy dashboard against them |
| Quotas | Protects shared clusters from many concurrent workbook refreshes | Limits query counts or time windows for the Tableau service user | Agree quota values with the platform owner before extract refresh schedules are set |
| External authenticator | Tableau users sign in to Tableau through their own identity provider, separate from database login | LDAP, Kerberos, SSL X.509 or JWT can map a directory identity to a ClickHouse user | Confirm which identity source the database login uses and who can revoke it |
Securing analyst access from Tableau
Analysts connecting Tableau to a self-hosted ClickHouse cluster reach it through the same HTTP interface and user accounts as every other client, so the access controls below apply to the workbook path too. Together they cover how the connection is encrypted, who is allowed to log in, what each login can read and how much load it can place on the cluster.
Encrypt the HTTP interface
Tableau's JDBC connection carries credentials and query results over the ClickHouse HTTP interface, so that interface should accept TLS connections only for analyst traffic. Confirm the certificate chain is trusted by the machine running Tableau Desktop and by Tableau Server or Tableau Cloud gateways, because a certificate the client rejects will surface as a generic connection failure. Ask the vendor-supplied JDBC driver version to match the TLS settings you configure.
One read-only user per team
Create a separate, non-default user for each analyst group rather than sharing one login across a department. Grant only the SELECT rights on the databases and tables that group needs, and keep write and DDL privileges with the platform team. Separate users make it possible to see which team's workbooks produced a heavy query and to revoke one team's access without affecting others.
Restrict the default user
A fresh ClickHouse installation starts with a default user that has all permissions, so Tableau should never be pointed at it. Confirm that the default user is disabled for network logins or has its password and network access locked down before analysts receive connection details. Keep the account for break-glass administration only, with its use logged and reviewed.
Quotas and settings profiles
Interactive dashboards can run many queries at once, and a single wide dashboard refresh can scan large parts of a table. Assign analyst users a settings profile that caps query memory, execution time and result size, and a quota that limits queries per interval. Test the limits with the heaviest workbook your team expects, and agree with analysts what happens when a dashboard hits a limit.
External authentication options
ClickHouse can delegate login to LDAP directories, Kerberos, SSL X.509 client certificates, an HTTP authenticator or JWT tokens. Choose the option your identity estate already operates, and confirm with the vendor documentation that the JDBC driver and Tableau connection settings support that method for your ClickHouse version. Where the method needs extra client-side configuration, such as a certificate or Kerberos ticket on each analyst machine, include that in the rollout plan.
Keep credentials out of workbooks
Tableau workbooks can carry saved connection details, and a published workbook may be shared with people who should never see a database password. Require analysts to sign in with their own credentials or use Tableau Server or Tableau Cloud credential storage, and avoid embedding passwords in .twb or .twbx files. Audit published workbooks periodically, and rotate any credential that was ever saved into a shared file.
Common Tableau to ClickHouse connection failures
This table lists the failures teams most often hit when Tableau reaches a self-hosted ClickHouse cluster, with the likely cause and a general fix for each. Check every fix against the ClickHouse and connector versions you run, because driver and server behavior changes between releases.
| Failure | Likely cause | Fix to verify |
|---|---|---|
| Driver version mismatch | The JDBC driver or connector build is older or newer than the ClickHouse server supports, so queries or metadata calls fail. | Pair the connector and JDBC driver versions with your server release, then test a simple table preview before publishing. |
| TLS or certificate trust errors | Tableau does not trust the internal certificate authority or the hostname does not match the certificate. | Install the internal CA in the Tableau host trust store, confirm the hostname matches the certificate, and enable TLS on the HTTPS port. |
| Network blocked to the HTTP port | A firewall, security group or proxy blocks the ClickHouse HTTP(S) port between the Tableau server or Desktop and the cluster. | Open the configured HTTP or HTTPS port from the Tableau host, then test with a plain connection from that machine before opening Tableau. |
| User lacks grants on a database | The analyst account has no SELECT grant on the target database or table, so Tableau shows an empty or failed schema list. | Grant SELECT on the specific databases and tables through a role, and confirm the role is assigned to the user as well as the default roles. |
| Tableau timeouts on heavy live queries | Dashboards issue wide scans or many concurrent live queries that exceed Tableau's wait time or the server's query limits. | Reduce dashboard query load, move heavy views to extracts or summary tables, and review server-side query and memory limits with your cluster team. |
| Nullable or unsupported type surprises | Nullable columns, arrays, or other ClickHouse types map to Tableau types differently, causing unexpected nulls or failed field creation. | Check the field mapping in Tableau after connecting, wrap problem columns in views with explicit casts, and confirm the connector's documented type support for your version. |
| Extract refresh fails on large tables | The extract job exceeds memory, temporary disk or time limits on the Tableau side, or the ClickHouse query times out during the full read. | Extract in incremental slices by partition or date range, check free disk on the Tableau host, and confirm refresh timeouts with your Tableau administrator. |
Questions buyers ask before connecting Tableau to ClickHouse
Who has to configure the cluster, the connector and the access model?
Three groups share the work, and each one is a separate cost line. The database owner prepares the ClickHouse side: a dedicated read-only user, roles, row policies where analysts should see only part of a table, and network reachability for the Tableau host. Your Tableau administrator installs the official connector from Tableau Exchange, sets up the JDBC driver on the machine that runs Tableau, and publishes data sources. The data owners decide which tables and columns analysts may see. A partner can take any of these pieces under a written scope, but the decisions about who may see what stay with your organization. Ask any quote to list each group and its tasks separately, so you can see which work your staff would absorb.
What drives the cost of connecting Tableau to ClickHouse?
The main drivers are the number of data sources, the complexity of the access design, the size of the tables analysts query, and how much dashboard tuning is needed. A single read-only user over one curated table is a small task. Many departments with different row-level rules, plus extracts that must refresh on a schedule, add design and testing work. Cost is mostly one-time: building the connection, access model and documentation. Recurring cost appears when new data sources, new analysts or Tableau or ClickHouse upgrades arrive. Ask the quote to separate build work from any retainer for ongoing support.
How long does a Tableau connection to ClickHouse take?
The duration depends mostly on the access design and the data volume, not on the connector itself. A connection to one approved table for a small group can be validated quickly once the network path and credentials exist. Time grows when row policies must match an existing identity model, when data owners need to review which columns to expose, or when large tables need aggregated sources or extracts tuned before analysts use them. Large volumes also require testing with representative queries. Ask for a schedule that lists these checkpoints, and treat any timeline without them as an estimate to challenge.
What must our team provide before the work starts?
Expect to supply the following before work begins:
- Network access from the Tableau host, or from a gateway, to the ClickHouse HTTP or native ports, and a clear firewall change record
- Cluster access for administrative setup, plus a test environment with representative data if you have one
- TLS certificates issued by your certificate authority, and the CA chain the Tableau machine must trust
- Tableau licensing for the people who will build and publish dashboards, and Tableau Server or Cloud details if you publish there
- Named data owners who approve which databases, tables and columns analysts may query
- A list of the identity sources analysts already use, so access can follow existing groups
Confirm the exact ClickHouse ports and certificate requirements against your own environment and the connector documentation before you commit to a date.
Can our internal team connect Tableau to ClickHouse without a partner?
Yes, a team with ClickHouse administration experience and Tableau skills can do the work in-house. The connector is documented, and the steps are the same as in the vendor guide. The risk sits in the access model. Mistakes such as sharing the default user, granting write permissions to a dashboard account, or exposing a raw table with sensitive columns are easy to make and hard to notice later. Check whether your team has someone who owns ClickHouse users, roles and row policies, and whether they can test restricted accounts before analysts log in. If that skill is missing, a fixed-scope engagement can cover only the access design and review.
How does a fixed-scope engagement or support retainer change the work?
A fixed-scope engagement agrees the scope, deliverables and timeline in writing before work starts, so the connection, access model, test results and handover notes are defined up front. Changes such as a new data source or additional dashboards go through a written change to the scope. A support retainer covers work that continues after go-live, such as adding analysts, reviewing access requests, handling connector or driver updates, and tuning dashboards as data grows. Ask for the response expectations and exclusions in writing. DeployOpen does not publish a price list, so the quote follows from the scope you agree.
Which ClickHouse version should we check before connecting Tableau?
Start with the version your cluster runs, then check it against the ClickHouse security policy, which lists the versions that receive security updates. Versions outside that list no longer get security fixes, so a connection built on them creates a patching obligation. The production guidance recommends stable releases for most production use and reading the changelog before any upgrade, because minor backward-incompatible changes can occur. Confirm connector and JDBC driver compatibility with the version you run, since the driver and the server must be matched. Plan a test of the Tableau workbooks against any new release before you change the production cluster.
Do analysts need direct access to the ClickHouse cluster?
Analysts should not need administrative access, and most organizations should avoid giving them the default user. Build a dedicated read-only account for Tableau, restrict it to the databases and tables it needs, and apply row policies where departments must see different records. Analysts then reach data through published Tableau data sources. Confirm the external authentication method your organization uses, such as LDAP, Kerberos or certificates, before choosing a shared password, because a shared password is hard to rotate and to audit. Ask whether the access model will be tested with a non-administrative account before go-live.
Official Tableau connector documentation
Start with the official ClickHouse guide for connecting Tableau before you configure anything. It covers the connector that ClickHouse publishes on Tableau Exchange, which is built on the ClickHouse JDBC driver and exposes databases and tables from your cluster as Tableau data sources. Treat the guide as the reference for the connection steps, and use it to confirm the prerequisites for your Tableau version and your ClickHouse server version before you schedule any installation work. Where the guide and your internal runbook disagree, the guide wins until your team has tested the difference.
Check the release notes for the connector and the JDBC driver version you actually install, not only the latest version listed on Tableau Exchange. Note the driver version, the Tableau Desktop and Tableau Server or Cloud versions it supports, and any changes to how it handles TLS, authentication or data types. Record the versions in your deployment documentation so that an analyst's workstation, a Tableau Server node and a future upgrade all point to the same tested combination. If the release notes mention a change that affects your environment, add a pre-production test with representative queries before the connector reaches analysts.
Confirm the support path before you go live. Ask ClickHouse and your own Tableau administrators which component you will troubleshoot first: the connector, the driver, the network path or the cluster. Agree who owns each upgrade of the connector, the driver and the Tableau installation, and how a rollback would be carried out if a new combination fails. Writing these answers down now avoids guessing during an incident, when an analyst reports that a data source has stopped refreshing.
How DeployOpen scopes and delivers the Tableau connection
DeployOpen plans, builds and hands over the Tableau connection to a ClickHouse cluster inside your own infrastructure. Engagements are fixed-scope, so the connector setup, network path, access model and test steps are agreed in writing before any work starts.
How we scope
- Inventory which Tableau products, versions and deployment models your analysts use, including Tableau Desktop and Tableau Server or Cloud if applicable.
- Map which ClickHouse databases, tables and views Tableau should expose, and which should stay out of reach.
- Confirm the network path from Tableau to ClickHouse, including gateways, TLS termination and firewall rules, and record it in the written scope.
How we build
- Install and configure the official ClickHouse Tableau connector with the ClickHouse JDBC driver version your environment supports.
- Create dedicated read-only ClickHouse users, roles and row policies for analyst groups rather than sharing the default user.
- Test live and extract data sources against representative tables and queries, and record query timings before analysts rely on them.
How we hand over
- Deliver a runbook covering connection settings, credential rotation, driver upgrades and the live versus extract decision for each dashboard.
- Document the access model, including which roles map to which Tableau users and how access is requested and removed.
- Walk through the connection with your data and platform team so they can add data sources and troubleshoot connection errors independently.
How we support
- Ongoing support, driver updates and ClickHouse version changes can be covered by a retainer agreed in writing.
- Review Tableau query load and slow dashboards on a schedule, and adjust extracts, views or permissions where needed.
- Re-test the connection after each ClickHouse or Tableau upgrade, using the same test set from the original handover.
