How self-managed ClickHouse helps you keep EU analytics data in the EU
Self-managed ClickHouse can help you keep EU analytics data in the EU, but it does not settle residency on its own. Running the cluster in your own cloud accounts or data centers removes a third-party processor from the storage path, which is the starting point for a defensible position. Residency is still a legal and operational outcome that the controller must assess, document and keep true over time. The ClickHouse server is open source under the Apache License 2.0, so the software carries no license-driven dependency on a vendor's hosting, and the location of every component is decided by your architecture.
Chapter V of the GDPR applies to more than where data is first stored. Under Article 44, every transfer of personal data to a third country, including onward transfers, must meet Chapter V conditions. The EDPB Guidelines 05/2021 (version 2.0) make two points that matter for ClickHouse operations: remote access from a third country, even only displaying data on a screen for support or administration, is a transfer, and so is storage in a cloud outside the EEA. A cluster hosted in an EU region can still breach these rules if an engineer abroad queries production tables, if a support vendor connects from outside the EEA, or if backups are copied to a bucket in another region. Infringements of Articles 44 to 49 carry fines of up to EUR 20 million or 4% of worldwide annual turnover under Article 83(5)(c).
Your first decision is to map every location where ClickHouse data exists: data parts on disk, replicas, Keeper nodes, logs, BACKUP destinations on S3-compatible or Azure Blob storage, and the paths your operators use to reach the cluster. Confirm with your cloud or data center provider where each one physically sits and who can access it. DeployOpen plans, implements and documents these systems and gathers the evidence an assessor will ask for, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies provide those, and the controller remains responsible for the residency position.
Which residency requirements map to which ClickHouse settings
This table pairs each EU residency requirement with the ClickHouse capability that addresses it and the evidence an assessor will ask for. Read each row as a question: where does the data sit, who can reach it from outside the EU, and can an order from a third-country authority reach it. The main takeaway is that ClickHouse settings control location and access, but the choice of hosting, backup destination and support access decides whether the transfer position holds.
| Requirement | ClickHouse setting or control | Evidence to keep |
|---|---|---|
| GDPR Article 44: transfers to third countries, including onward transfers | Place storage disks, replicas and backup destinations only in EU regions you contract for and control | Architecture diagram with region of every node, disk and bucket, plus the transfer map |
| EDPB guidance: remote access from a third country is a transfer | Restrict network paths and default user; limit operator and vendor sessions to EU-based staff through access control and jump hosts | Access list showing who connects, from where, and the role each account holds |
| Article 48: third-country court or authority orders | No ClickHouse setting removes this exposure; it depends on who operates the platform and where its legal control sits | Documented assessment of the processor's exposure to third-country law before engagement |
| 18 U.S.C. 2713 (CLOUD Act) reach over US providers | Choose infrastructure and support providers with no US parent or control over the hosted data; confirm this with each vendor in writing | Written confirmation from each provider covering hosting, support and backup services |
| Data Act Article 32: safeguards against third-country access to non-personal data in the Union | Keep data, metadata and backups on EU infrastructure you operate; document the measures taken | Records of the legal and technical measures and their review dates |
| Article 32 GDPR: security of processing | TLS, X.509 client certificates, LDAP, Kerberos, HTTP or JWT external authenticators for sign-in | Authentication configuration export and test results for each login path |
| Access control within the EU boundary | Users, roles, row policies and settings profiles; restrict the default user, which starts with all permissions | Role matrix, row policy list and periodic access review records |
| Backup location and restore integrity | BACKUP and RESTORE to S3-compatible or Azure Blob Storage located inside the EU; test restores on a spare cluster | Backup destination records, encryption settings and dated restore test results |
Where ClickHouse data, backups and object storage must live
Residency is decided by every place a copy of the data can exist, not only by the primary cluster. Start by listing them: data parts on the local disks of each ClickHouse node, the replicas that hold the same ReplicatedMergeTree data on other nodes, the ClickHouse Keeper nodes that coordinate replication, backup destinations on local disk or in S3-compatible or Azure Blob Storage, and the system tables such as system.query_log that record query text and, depending on settings, parameters and results. Each of these can contain personal data, so each needs a documented location inside the EU or EEA. Object storage buckets used for tiered storage or backups need the same check, including their replication or cross-region settings, which many providers enable by default or offer as an option.
Residency also covers copies you do not create directly. Hosting providers take disk snapshots, volume replicas and provider-side backups of virtual machines and block storage, and some keep logs or support diagnostics that include query text. Under Article 44 of the GDPR, an onward transfer outside the EU or EEA needs its own legal basis, so a snapshot stored in another region is a transfer even if your team never touched it. Ask the provider where snapshots, replicas, control-plane logs and support tooling run, whether they are encrypted with keys you control, and which entity operates each service.
Confirm all of this with the hosting provider in writing, and keep the answer with your records of processing. The confirmation should name the region or data center for each storage class, the location of snapshots and provider-managed backups, and the regions used for failover and disaster recovery. Then check the ClickHouse side against it: list the disks in the storage configuration, the BACKUP destination paths, the bucket names and endpoints, and the hosts in the Keeper ensemble, and compare each one with the written answer. Repeat the check after every new node, disk or backup target, because residency drifts quietly when a team adds capacity in a convenient region.
Operator access that can turn a support session into a transfer
Under the EDPB's reading, a screen shared from a third country can count as a transfer, so the people who can touch the cluster matter as much as where it runs. The six cards below cover the access paths that most often bypass an EU-only architecture, and the controls to decide on before any support session begins.
Remote support from third countries
A vendor engineer in another country who connects to a bastion, reads a console or screen-shares a dashboard may be making a restricted transfer, even when no data is copied. Decide in advance which support tasks may be performed remotely, from which countries, and through which jump host. Require that every session is logged with the operator's identity and the reason for access. Ask the vendor to confirm in writing where their support staff sit and whether they can be restricted to EU locations.
Follow-the-sun operations staff
A 24-hour operations model often routes incidents to teams in other time zones, some outside the EEA. Map each shift team to its location and employer, and decide which roles may see production data at all. Separate on-call diagnostic access from standing administrative rights, so an out-of-region engineer can restart a service without holding credentials to the data itself. Confirm how the staffing model changes if an incident runs past a regional handover.
Vendor-side log access
Support tickets often pull in ClickHouse logs, query logs and crash dumps, and those files can contain row samples, table names or query text with personal data. Decide which logs leave your environment, who receives them, and whether they are masked before export. Store vendor-bound extracts in an EU location you control and record each transfer as an approval event. Ask the vendor which systems hold copies of your diagnostics and for how long.
Backup restores from outside the EU
A restore test or a disaster recovery drill performed by a team abroad can move full copies of personal data across the border. Keep restore workstations, the spare cluster and the operators who run restores inside agreed locations. The backup documentation recommends regular restore tests on spare clusters, so schedule them in the EU and record who performed each one. Check where the object storage for backups sits and which keys can read it.
Screen sharing of query results
Screen sharing during a troubleshooting call exposes query results to anyone watching, and EDPB Guidelines 05/2021 treat mere display from a third country as a transfer. Agree a rule that support engineers view results on EU-hosted tools, mask sensitive columns in the client, and avoid pasting sample rows into chat. Prefer reproduction with synthetic or masked data. Make the rule part of the support runbook, not an informal habit.
Sub-processors and their access
Each sub-processor that can reach the environment, from hosting providers to ticketing, monitoring and chat tools, extends the chain of parties with access. Ask for a current list of sub-processors with locations and the access each one holds. Confirm that a third-country authority request reaching any of them is assessed before engagement, as the EDPB's Example 12 requires. Keep named accounts and approval records for every sub-processor that touches systems or logs.
How US and other third-country law reaches an EU deployment
An EU-owned operator with EU-only staff and EU-only administrative access has the smallest exposure to foreign legal reach, but it is not zero. The CLOUD Act provision at 18 U.S.C. 2713 applies to US providers of electronic communication and remote computing services, so it reaches a US company's control over data, not an EU operator with no US presence. Your remaining exposure comes from vendors and support channels: any US-headquartered software vendor, support contractor, cloud account owner or backup target that holds or can access the data may fall under US process. The EDPB's view is that remote access from a third country counts as a transfer, so a support engineer in another country viewing a screen is in scope.
- Map every party with access: list operators, vendors, support engineers and storage providers, and note the country and parent company of each.
- Check backup and object storage providers: a US-owned bucket service in an EU region can still be subject to US process.
- Restrict remote access paths: vendor remote sessions and break-glass accounts should be listed as potential transfers.
- Record the analysis: note which parties were considered and why each one was accepted or excluded.
- Confirm with counsel: ask whether any EU entity in the chain has a US parent or US affiliate with control over the data.
Check the operator and vendor list against the transfer impact assessment before the cluster goes live.
A group whose parent sits outside the EU faces a different question. Under the CLOUD Act, a US parent that controls the data, directly or through its subsidiary, may be compelled to preserve or disclose it regardless of where the servers stand. The GDPR also treats onward transfers as covered by Chapter V, so the group must check whether data flows from the EU entity to the parent for group reporting, shared support or central security monitoring. Article 48 limits how far foreign judgments can be enforced in the EU, but it does not stop a US provider from complying with a request directly.
- Trace control, not just location: a request follows control over the data, so the parent's ability to access the cluster matters more than the data center.
- Review group access: parent-company staff with admin, log or backup rights are an exposure point.
- Check intra-group transfer terms: identify whether standard contractual clauses under Commission Implementing Decision (EU) 2021/914 cover the flows.
- Document the authority assessment: record the laws the parent is subject to and the likely requests it could receive.
- Plan for a request: write down how the group would notify its data protection officer and assess a request before responding.
Ask counsel whether the parent's legal obligations could require disclosure that conflicts with EU law.
When the hosting provider is US-owned, the provider is the most direct point of foreign legal reach, even if it operates EU data centers. The EDPB's Example 12 in Guidelines 05/2021 says that using an EU processor subject to third-country law with extraterritorial effect is not itself a transfer, but complying with a third-country authority request would be. The Data Privacy Framework (Commission Implementing Decision (EU) 2023/1795) can cover transfers to certified US organizations, but the General Court upheld it in September 2025 and an appeal in Case C-703/25 P is pending. The EDPB Recommendations 01/2020 state that where the destination's public authority powers go beyond what is necessary and proportionate, an effective technical supplementary measure cannot be envisioned, which means encryption alone may not settle the question.
- Check the framework status: confirm whether the provider is on the Data Privacy Framework List and track Case C-703/25 P.
- Do not rely on the framework alone: a pending appeal means a future invalidation is possible.
- Assess technical measures honestly: where the provider holds keys or processes data in the clear, encryption may not address access powers.
- Compare alternatives: consider an EU-owned host or on-premises deployment where the access power cannot be exercised.
- Document the decision: record why the provider was accepted, the residual risk and the review trigger.
Request the provider's written position on government access requests and its transparency reporting.
Whatever the ownership structure, the recommendation is a documented transfer impact assessment that covers each party with access to the cluster, the storage and the backups. The assessment should describe the data, the flows, the laws that could apply to each party, the safeguards in place and the conclusion. It does not produce an audit report or certification; it is an internal record that your data protection officer, counsel and auditors can review. The GDPR requires no certificate, and certification under Article 42 does not reduce the controller's responsibility.
- Scope the flows: list every location where data, backups, logs and metrics are stored or viewed.
- Name the legal reach: state which third-country laws apply to each party and the mechanism that reaches the data.
- Record supplementary measures: describe encryption, key custody, access logging and contractual commitments, and state their limits.
- Set review triggers: include events such as a court ruling on the Data Privacy Framework, a change in vendor ownership or a new support path.
- Assign ownership: name who signs off, who reviews annually and who handles government access requests.
Have counsel and your data protection officer review the assessment before it is relied on.
What a managed ClickHouse service changes for residency
Who operates the control plane when ClickHouse runs as a managed service?
In a managed service, the provider usually operates the control plane, which covers provisioning, upgrades, scaling, and often the service's management and monitoring consoles. Self-managed ClickHouse keeps that work inside your own team or your own infrastructure, so the operator accounts and their logs sit with you. Ask the provider to document which components run in which account, who holds administrative roles, and where support sessions are initiated. The ClickHouse server itself is open source under the Apache License 2.0, so the software is the same whichever way you run it, but the operating model is not. Confirm these points in writing before you decide.
Where does managed ClickHouse storage physically sit?
Managed storage sits wherever the provider places it, which is not always the region or country you chose for your own cluster. Under the GDPR, storage of personal data in a cloud outside the EEA is a transfer under Chapter V, according to EDPB Guidelines 05/2021. Ask the provider to name the exact region, the data centers used, and whether backups, logs, metadata and support copies are stored in the same region. Confirm whether any replication or failover path crosses a border. Do not assume that a region label in a console means that every copy stays inside the EEA.
What can a managed service provider access in your data?
The answer depends on the contract, the service design and the provider's own operating practices, so you need to confirm it in writing. Remote access from a third country is itself a transfer under the EDPB guidance, even when staff only view data on a screen for support. Under 18 U.S.C. 2713, US providers must preserve or disclose data in their possession, custody or control regardless of location, which is why the provider's corporate domicile matters. Ask which support staff can reach customer data, from which countries, under what approval, and how access is logged and reviewed.
Does a third-country authority request reach EU-hosted managed data?
It can, if the provider is subject to third-country law with extraterritorial effect. The EDPB's Example 12 explains that using an EU processor subject to such law is not in itself a transfer, but complying with a third-country authority request would be. Controllers should assess that exposure before engaging the processor. GDPR Article 48 limits recognition of foreign disclosure orders to those based on an international agreement in force with the Union or a Member State. Ask the provider how it handles government requests, whether it notifies customers, and what contractual commitments it makes on challenging overbroad requests.
How does exit work under the EU Data Act?
The Data Act, applicable since 12 September 2025, gives customers the right to switch from a data processing service to another provider or to on-premises infrastructure. Articles 25, 29 and 50 of Regulation (EU) 2023/2854 set a maximum two-month notice period and a 30-day transition, and ban switching charges from 12 January 2027. Ask the provider for its switching procedure, the data export formats it supports, and how it returns backups and metadata. Because self-managed ClickHouse already runs on your infrastructure, the exit path is mostly about data export and table schema, so test it before you need it.
Is the region choice contractual, and how can you verify it?
Confirm whether the region is a contractual commitment or only a default setting. A console selection is not the same as a binding term that covers backups, logs, support access and sub-processors. Ask the provider to list its sub-processors, the locations where each one processes data, and how it notifies you of changes. Request written confirmation of region commitments for every data category you hold. Then verify the configuration yourself with periodic checks against the provider's documentation, since a contract describes intent and only evidence shows the actual placement.
Does a managed service remove your own residency work?
No. A managed service changes who runs the platform, but the controller still carries its GDPR obligations, including the transfer assessment, records of processing and security of processing under Article 32. Self-managed ClickHouse keeps those decisions in your hands, while a managed service adds a processor relationship you must document and monitor. Use the questions above to decide which work moves to the provider and which stays with your team. Ask any partner, including DeployOpen, to write its scope of responsibility for each of those tasks before work starts.
What should you ask a managed provider before signing?
Ask for the following in writing: the named regions for compute, storage, backups and logs; the list of sub-processors with their locations; the support access model, including which countries staff work from; the process for government requests; the switching and export procedure under the Data Act; and the notice period for changes. Ask whether the provider accepts audit or evidence requests and what evidence it supplies. Confirm the answers with the provider and with your legal counsel. These are questions to confirm, not assumptions to carry into your risk register.
Configuring an EU-resident ClickHouse deployment
This sequence turns an EU residency decision into a deployment where personal data, replicas, Keeper nodes, backups, accounts and operator access all sit inside infrastructure you control. Each step ends with a check you can show an auditor or your data protection officer.
Map data flows and classify personal data
Before choosing hardware, the data protection lead and the platform team list every source that writes to ClickHouse, every table, every consumer and every place a copy lands, including logs, dashboards and exports. Mark which fields are personal data under the GDPR and which are pseudonymized or aggregated. The step is done when the data map has a named owner for each table and each flow, and when no flow reaches a system the team has not yet approved. Confirm the scope with counsel if any data concerns special categories or regulated sectors.
Select EU hosting and sub-processors
Choose data centers, cloud regions or private facilities located in the EEA for every component that stores or processes the data: database hosts, Keeper hosts, backup targets, object storage, monitoring and log pipelines. Review each provider's sub-processor list and the support locations that could reach your systems. Under EDPB Guidelines 05/2021, storage in a cloud outside the EEA is a transfer, and remote access from a third country, even for support, counts too. The step is done when a written register lists each provider, its region, its sub-processors and its remote access paths, and the register is approved by the controller.
Deploy replicas and Keeper on dedicated hosts
The platform team deploys ClickHouse replicas with ReplicatedMergeTree tables and at least three ClickHouse Keeper nodes on dedicated hosts, as the replication guide recommends for production. Keep all nodes in the same EU jurisdictions you selected in the previous step and avoid placing Keeper on the database hosts. Confirm the Keeper RAM sizing against the guide's figure of about 4 GB per node. The step is done when a test table written on one replica appears on the others, and when stopping one replica and restarting it shows it syncing the missing data from a healthy replica without manual steps.
Set BACKUP destinations inside the EU
Configure BACKUP and RESTORE targets, whether local disk, S3-compatible storage or Azure Blob Storage, in EU-located storage that is under your control. Replication does not protect against deletion or corruption, so backups must be separate from the replicas and must not sit in a bucket or account administered from a third country. Confirm that object storage encryption keys are held in the EU and that backup credentials are scoped to the backup role only. The step is done when a backup runs to the EU target, the target location is documented, and a restore to a spare cluster succeeds, since the backup documentation warns that an untested backup will probably not restore when needed.
Restrict the default user and create roles
The security lead disables or locks down the default user, which starts with all permissions, and creates named users assigned to roles that follow the data map from step one. Use the SQL-driven access control workflow for users, roles, row policies, settings profiles and quotas, and apply row policies where a team should see only its own tenant or region. The step is done when a login attempt with the default user is refused in production, every human and service account maps to one role, and a query of the access control system tables matches the approved access matrix.
Configure external authenticators
Connect ClickHouse to your identity provider using the external authenticators it supports, such as LDAP directories, Kerberos, SSL X.509 certificates, an HTTP authenticator or JWT authentication, so that user lifecycle stays in the directory you already run in the EU. Confirm which mechanisms your identity estate can operate and document who controls the directory. The step is done when a user removed from the directory can no longer authenticate, and when a test account with a role outside its permitted tables receives an access denied response.
Document operator access paths
List every way a person or system can reach the cluster: SSH to hosts, Kubernetes API access, console and management tooling, vendor or contractor support sessions, and log exports. For each path, record where the operator is physically and legally located, whether the session could display or transfer personal data, and who approves it. Under EDPB Guidelines 05/2021, even displaying data on a screen for support is a transfer, so out-of-EEA support paths need a decision before they are used. The step is done when the register is signed off, each path has a named approver, and a test session from an unapproved location is blocked at the network or identity layer.
Evidence that shows where data lived and who touched it
A residency claim is only as strong as the records behind it. The items below connect where ClickHouse servers, backups and object storage sit, who can reach them, which versions run, and how each transfer question was assessed. Retain them together so one review can trace a dataset from ingestion to restore.
Infrastructure location records
Keep a dated inventory of every host, Keeper node, data center, region and cloud account that stores or processes ClickHouse data, including replicas and any disaster recovery site. Record the physical or legal location of each, and the operator who controls it. Check that the inventory matches what the cluster reports, not only what the architecture diagram shows, because a forgotten replica or log shipper can sit outside the EEA. Auditors and supervisory authorities make the final determination on whether these locations meet your obligations.
Backup destination configuration
Export the configuration that defines where BACKUP writes, whether a local disk, an S3-compatible bucket or Azure Blob Storage, and version it with change records. Confirm the bucket or container region, the account that owns it, and whether any copy is replicated to a location outside the EEA. Backups often hold the full historical dataset, so a backup in the wrong place can be a transfer even when the live cluster is compliant. Ask your provider to confirm where object storage replicas physically reside.
Restore test records
The backup documentation warns that a backup never test-restored will probably not restore properly when needed, so keep dated records of restore tests on a spare cluster. Note which backup was restored, the target location, who ran the test, and whether row counts and checksums matched. Confirm that restore tests were run inside the EU as well, because restoring a copy into a non-EU environment creates the same transfer question as the original write.
Access and authenticator configuration
Retain the exported user, role, row policy and settings profile definitions, plus the external authenticator configuration for LDAP, Kerberos, X.509 or JWT. These show who can read data and from where. Restrict the default user, which starts with all permissions, and record that change. Remote access from a third country, even only displaying data on a screen for support, counts as a transfer under the EDPB guidelines, so include the IP ranges and identity providers that support engineers use and the locations they connect from.
Query and session logs
Preserve the system tables that record logins and queries, and export them to storage inside your EU boundary on a defined schedule. These logs answer the question of who touched the data and whether any operator session originated from outside the approved locations. Set a retention period that matches your policy, mask sensitive literals before export, and confirm that the log store itself is not shipped to a SaaS platform outside the EU.
Version and support status records
Keep a dated record of the ClickHouse version running in each environment and compare it with the security policy, which lists the currently supported versions and marks all others as unsupported. An unsupported build is a security exposure that a supervisory authority may ask about, so file each upgrade with its changelog review and pre-production test. Record the release channel you chose, stable or LTS, and the date you confirmed its support status.
Transfer impact assessment records
Document the assessment of whether any processor, sub-processor or support provider could be subject to third-country law that requires disclosure of EU data. Record the contract terms, the supplementary measures you relied on, and the conclusion reached. EDPB Recommendations 01/2020 state that where a provider needs access to data in the clear and third-country powers go beyond what is necessary and proportionate, no effective technical supplementary measure can be envisioned. Review these records when the legal framework changes.
Questions teams ask before running ClickHouse for EU data
What drives the cost of an EU data residency deployment of ClickHouse?
The main cost drivers are the number of clusters, the number of regions and sites that must stay inside the EU, the size and growth of the data, the Keeper and replica layout, and how many systems connect to ClickHouse. Costs fall into one-time work (architecture, build, migration, initial backup and restore tests, documentation) and recurring work (upgrades, monitoring, access reviews, restore tests and infrastructure). Your own infrastructure costs are paid to your cloud or data center providers, while a partner is paid for the written scope. Ask any quote to separate one-time and recurring items, and to state which evidence and restore tests are included.
How long does an EU ClickHouse deployment take and what does it need from us?
Duration depends on the number of environments, the data volume, how many source systems must be connected, and how quickly your team can approve cloud accounts, networks, identity sources and change windows. No fixed timeline applies to every deployment, so ask for a duration in the written scope rather than relying on a general figure. You will need to provide EU-located infrastructure access, a named owner for data classification, identity and access decisions, a representative dataset for a pre-production test, and the people who approve changes. Legal review of transfer and processor terms usually runs in parallel.
Can our internal team run ClickHouse for EU data without a partner?
Often yes, if your team already operates Linux, Kubernetes or database clusters and has the time to build the skills. Check four things: whether you can run a three-node ClickHouse Keeper ensemble on dedicated hosts, whether you can run regular BACKUP and RESTORE tests on a spare cluster, whether you can keep up with the release cadence and the supported version list, and whether someone owns access reviews and logs. A partner is useful when the team lacks capacity for the first build, the compliance evidence, or the restore testing. Many organizations split the work between internal ownership and external build support.
Does ClickHouse Cloud in an EU region remove the need for this analysis?
No. A region choice tells you where the service runs, but it does not settle who can access the data, where support staff are located, where backups and metadata are held, or whether a non-EU parent company or sub-processor can be compelled to disclose data. The EDPB guidance treats remote access from a third country and storage outside the EEA as transfers, so you still need to map each party and location. Ask the provider for its written processing terms, sub-processor list, support access model and the location of backups and logs. Self-managed deployments in your own infrastructure make these questions easier to answer, but they still require your own assessment.
How do backups affect data residency for self-managed ClickHouse?
A backup is a copy of personal data, so it is subject to the same residency rules as the live data. ClickHouse BACKUP can write to local disk, S3-compatible storage or Azure Blob Storage, so the destination bucket, its region, its provider and the people who can read it all need to be inside your EU boundary. Replication does not protect against human error or corruption, so backups must be kept separately. Confirm the storage location, encryption keys, retention period and access logs, and include backup copies in your erasure and retention procedures. Restore tests should run on spare infrastructure in the EU as well.
What does DeployOpen deliver for an EU ClickHouse engagement?
DeployOpen plans, implements, hardens, backs up, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For EU residency work, deliverables are agreed in a written, fixed scope and typically include an architecture and data-location map, the deployed cluster with replication and Keeper, backup configuration and restore tests, access control configuration, and the operating documentation. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications, and legal conclusions about transfers remain with your counsel and the relevant authorities. Ongoing support and upgrades are available as retainers.
Which version of ClickHouse should we choose for an EU deployment?
Choose a version that is on the current security support list, and test it before production. The ClickHouse security policy lists versions 26.9, 26.8, 26.7 and 26.3 as supported with security updates, and all other versions as unsupported. The production FAQ recommends stable releases for most production use, a pre-production environment with representative data and queries, and reading the changelog before any upgrade, because minor backward-incompatible changes can occur. Confirm the chosen line against the security policy at the time of the decision, and record the version in your change records.
How DeployOpen scopes EU residency work for ClickHouse
DeployOpen is a Chainscore Labs company. We plan, implement, harden and document self-hosted platforms inside your own infrastructure, including ClickHouse clusters in the cloud accounts, data centers or restricted networks you control. Most engagements are fixed-scope, and the scope is agreed in writing before any work starts. For residency work, that written scope should name each location in the data path: the hosts running ClickHouse Keeper and replicas, the object storage that receives BACKUP output, the regions where operator accounts sign in, and any support tooling that could display rows on a screen. Where a location is outside the EEA, the scope should say so and record the assessment for it.
The residency evidence pack is a deliverable we produce alongside the build. It documents the placement of each replica, Keeper node and backup target, the network rules that keep traffic inside the agreed boundary, the list of operator roles and who holds them, and the restore test results. It is evidence for your own assessors and your records. It is not an audit report, an attestation or a certification, and DeployOpen does not issue any of these. Independent auditors and certification bodies make those determinations, and the contents of the pack should be reviewed with your legal counsel and data protection officer before you rely on them. DeployOpen does not publish a price list. A quote follows from the written scope, so ask for the scope items, assumptions and exclusions to be listed explicitly. Ongoing support, upgrades and continuous testing are available as retainers, which suit the periodic re-check of backup locations and operator access after the initial build.
