Why ClickHouse fits plant telemetry, and what changes when you run it yourself
ClickHouse suits plant telemetry when the data stays in infrastructure the plant or company controls. Machine and sensor data from several plants arrives at high rates, operators need short queries over recent readings, and quality and maintenance teams need years of history scanned in aggregate. That mix of high-volume appends and analytical reads is the pattern ClickHouse is built for. The server is open source under the Apache License 2.0 (SPDX: Apache-2.0), so you can run it on plant or data center hosts without a per-node license. ClickHouse Inc. sells ClickHouse Cloud separately as a managed service, which is a different operating model and a different data location decision.
Running it yourself moves several jobs onto your team. Schema design becomes yours: ordering keys, partitioning by plant and time, and rollup tables must fit the query patterns of each site, and a schema that works for one plant may need changes before it scales across several. Retention becomes a configured policy rather than a default, so you decide how long raw readings stay before they are aggregated or deleted. Replication uses ReplicatedMergeTree tables coordinated by ClickHouse Keeper, which you must deploy and monitor. Backups are a separate job: the backup documentation notes that replication alone does not protect against human error or corruption, so you need scheduled BACKUP jobs and restore tests on a spare cluster. Upgrades also become your responsibility, and the production FAQ asks you to read the changelog and test on representative data first.
Confirm three things before you commit to a design. First, which ClickHouse release line each plant will run, using the ClickHouse security policy to check which versions still receive security updates. Second, whether plants have network paths that allow a central cluster to receive data, or whether each plant needs a local deployment that replicates to a central site. Third, who owns Keeper hosts, backups and restore tests at each site. Writing those owners down early saves rework when the first plant goes live and the second one is scoped.
Industrial and regulatory requirements that shape the telemetry build
This table maps the industrial security, OT, EU product and reporting rules most likely to reach a plant telemetry platform to the decisions they force on segmentation, logging, reporting and vendor software. Read each row as a question to answer with your compliance lead before the ClickHouse and Kafka design is fixed, since applicability depends on your sector, location and contracts.
| Requirement | What it means for the telemetry build | Evidence and where it usually fails |
|---|---|---|
| ISA/IEC 62443 asset owner program (ANSI/ISA-62443-2-1-2024) | Sets the security program the plant owner must run. ClickHouse and Kafka hosts sit inside the zone model, so they need named owners, change control and documented roles. | Assessors look for a current inventory and program records. Failure point: the telemetry stack is treated as IT and left outside the OT program. |
| Security risk assessment (ANSI/ISA-62443-3-2-2020) | Requires zones and conduits to be identified before design. Decide which sensor, broker and historian data crosses each conduit and at what rate. | Evidence is a zone and conduit diagram with the data flows. Failure point: the ClickHouse cluster is placed in the corporate network without a conduit review. |
| System security requirements and security levels (ISA-62443-3-3-2013) | Defines target security levels per zone, covering access control, data flow restriction and audit logging. Set the target level for the Kafka and ClickHouse zone explicitly. | Evidence is per-zone requirement mapping. Failure point: ClickHouse default user permissions and open listeners are left as shipped. |
| Component and supplier requirements (ANSI/ISA-62443-4-1-2018 and 4-2-2018) | These address product suppliers, not asset owners. Ask whether your ClickHouse and Kafka distributions, and any connectors, come with a documented secure development lifecycle and component security documentation. | ClickHouse publishes a security policy and Kafka documents its security overview, but neither is an IEC 62443 certificate. Confirm supplier evidence before citing it. |
| NIST SP 800-82 Rev. 3 (September 2023) | Guides OT security for industrial control systems, building systems and physical access. Use it to justify monitoring boundaries and to balance security with OT performance and safety requirements. | Failure point: analytics traffic is treated as harmless and allowed to reach PLC or SCADA networks for convenience. |
| NIS2 Annex II manufacturing scope | Manufacturing divisions NACE Rev. 2 26 to 30, and medical devices, are listed as critical sectors. Confirm whether your entity is in scope and whether it is essential or important. | In-scope status drives risk management and reporting duties. Failure point: the telemetry platform is excluded from the incident response plan. |
| NIS2 incident reporting timelines (Article 23(4)) | In-scope entities must send an early warning within 24 hours, a notification within 72 hours and a final report within one month of a significant incident. | Logs from Kafka, ClickHouse and the OT boundary must be retained and searchable fast enough to meet these clocks. Failure point: retention is set for cost and the evidence is gone. |
| Cyber Resilience Act reporting (Article 14, from 11 September 2026) | Manufacturers of products with digital elements must report actively exploited vulnerabilities and severe incidents. Applies to products you place on the market, so confirm whether your own machines or software count. | Track vendor patch and advisory feeds for ClickHouse and Kafka releases in your own asset list. Failure point: reporting duties are assumed to start in 2027 when the wider regulation applies. |
| Machinery Regulation cybersecurity requirement (Regulation (EU) 2023/1230, applies from 14 January 2027) | Requires machinery to be protected so that connecting another or remote device does not create a hazardous situation. Design read-only, one-way or tightly controlled write paths from the telemetry platform back to machines. | Evidence is the connection and remote access design plus the risk file. Failure point: a dashboard or alerting integration is given write access to a controller. |
Plant-level, site-level or central deployment: choosing where ClickHouse runs
In this placement, each plant runs its own ClickHouse deployment inside the OT network or a DMZ that the plant's controls team already governs. Telemetry arrives from local brokers or collectors and is queried locally, so dashboards and alarms keep working when the corporate network is unavailable. The cost is repetition: every site needs servers, storage, patching, backups and monitoring, and the replicas for each plant must be sized for that plant's data volume.
- Network paths: Data flows from the OT zone to the plant cluster across a segment the OT team controls. Corporate users reach plant data only through a defined gateway or are not given access at all.
- WAN outage: Local ingestion, queries and retention continue. Central reporting pauses until the link returns.
- Operations: The plant or site IT team usually runs it, often with remote support from a central platform team. Confirm who is on call for a plant at night.
- Keeper and replication: Production replication needs at least three ClickHouse Keeper nodes on dedicated hosts, each with about 4 GB of RAM, per the replication guide. Small plants may need to confirm whether three hosts per site is practical.
- Upgrades: Each plant becomes a separate upgrade and backup target, so the release cadence must be planned across all sites.
Confirm with the controls team which zone each plant's data may occupy before choosing this option.
A central cluster in the corporate data center or a private cloud receives telemetry from many plants over links that the network team has approved. This keeps the operating footprint small and gives analysts one place for cross-plant comparisons. It places more weight on the links between sites, because every plant depends on them for ingestion and for any control-relevant data that must be visible locally.
- Network paths: Each plant forwards data through a brokered or firewalled path, typically one-way or tightly scoped, with no inbound access from corporate networks into the OT zone.
- WAN outage: Plants must buffer data on local storage or in a local broker until the link recovers. Confirm how much buffer each site can hold for the outage durations the business accepts.
- Operations: A central platform team usually operates the cluster. Plant engineers consume the data but do not run the database.
- Keeper and replication: Replicas and Keeper nodes sit in the data center, where they can be placed across failure domains. Confirm that the data center has the power, cooling and network redundancy the replicas need.
- Data governance: Central storage can concentrate sensitive production data. Confirm which plants' data may be stored together and who may query it.
Ask the network team to document every firewall rule between the OT zone and the central cluster before the design is accepted.
The hybrid placement runs a small ClickHouse footprint at each plant that ingests and retains raw telemetry for local use, then replicates summaries, rollups or selected tables to a central cluster. Plants keep operating when the WAN is down, and headquarters still gets consolidated views. The trade-off is two tiers to design, operate and reconcile, and the risk that summaries drift from the raw data if the design is unclear.
- Network paths: The plant tier sends outbound-only traffic to the central tier. Define which tables replicate, how often and over which path, and whether replication is pull or push.
- WAN outage: Raw data remains queryable locally. The central view lags until replication catches up. Confirm the lag the business can tolerate.
- Operations: Plant IT runs the local tier and a central team runs the upper tier. Agree on who owns schema changes that affect both.
- Keeper and replication: Each tier that uses replication needs its own Keeper ensemble. Plants with only one host cannot provide the three-node Keeper layout the guide recommends for production, so confirm the design for small sites.
- Reconciliation: Test that central summaries match raw data on a schedule, and restore tests should cover both tiers.
Validate the replication lag, buffer size and failover behavior with the client's network and plant teams during discovery, because this placement depends most on those details.
Schema, ingestion and retention settings that matter for machine data
Machine data is high volume, arrives out of order and is queried by device and time window. The settings below decide whether a plant's ClickHouse cluster stays fast, keeps the data it must keep and survives a node failure. Verify each one with representative device counts, message rates and query patterns before production.
Ordering key by device and timestamp
The ORDER BY key on a MergeTree table decides how readings for one machine are laid out on disk. Putting the device identifier first and the timestamp second lets queries for one asset and one time window skip most data. Ask whether your devices share a common identifier scheme across lines and sites, because mixed identifiers make the key hard to change later. In a pre-production test, run your real dashboard and alarm queries against the key and compare scanned rows.
Monthly partitions aligned to retention
Partitioning by month lets retention and deletion work on whole partitions instead of row-by-row deletes. This matters when raw sensor data must be dropped after a fixed period while summaries are kept longer. Confirm with your quality and legal owners how long raw readings must be retained, since that sets the partition boundaries and the TTL rules that depend on them. Check that partition count stays manageable at your device volume during the test.
Kafka and MQTT ingestion with deduplication
Plant gateways often re-send messages after a network drop, so the same reading can arrive twice. ClickHouse can consume Kafka topics through its Kafka table engine, while MQTT usually needs a bridge into Kafka or another broker first. Deduplication depends on the table engine and on the insert pattern, so design a key per reading (device, sensor, timestamp, sequence) and test duplicate injection during pre-production. Confirm the bridge your plant networks can run and the delivery guarantees it provides.
Rollup views for minute and hour aggregates
Materialized views can write minute and hour aggregates as data arrives, so dashboards and reports do not scan raw readings for long periods. Choose aggregate functions that can be merged later, and decide which sensors need min, max, average or counts. Validate that rollups match raw-data results for a sample of devices and that late-arriving data is handled. Test rollup lag under peak ingestion, because a rollup that falls behind silently misreports trends.
TTL and tiered storage for raw versus summary data
TTL rules can delete raw readings after their retention period, move older parts to cheaper storage and keep summary tables for longer. This separates the cost of keeping years of trend data from the cost of keeping high-frequency raw samples. Confirm which storage tiers your plant hosting provides and their performance. Test that TTL moves and deletions run on schedule with production-sized partitions, and that queries across tiers still return correct results.
ReplicatedMergeTree with Keeper for plant availability
ReplicatedMergeTree tables keep copies of plant data on several servers, and ClickHouse Keeper coordinates them. The documentation recommends at least three Keeper nodes on dedicated hosts in production, each with about 4 GB of RAM. A recovered replica syncs missing data from a healthy replica automatically, but replication does not protect against bad deletes or corruption, so backups remain separate. Confirm whether plant networks can host three Keeper nodes and what happens to local dashboards if the link to the central site fails.
How rollups and tiered retention keep years of history affordable
Keep raw high-frequency samples for a short hot window and store aggregates for the longer periods, because most plant questions after a few weeks concern hourly or daily trends, not individual sensor readings. In ClickHouse this usually means a raw table with a TTL clause that expires samples after the hot window, plus one or more aggregate tables filled by materialized views. Those views typically hold per-tag averages, minimums, maximums and counts per interval, stored in an aggregating engine so they can be merged across parts. The raw and aggregate tables can carry different TTL expressions, so the aggregates survive long after the raw samples are gone. Before you build this, agree on which aggregates each engineering and maintenance team actually uses, since a rollup that drops a needed statistic cannot be recreated from data that has already expired.
TTL rules can delete rows or move data to another volume or disk defined in the storage configuration, and the tier options themselves are covered in the storage, tiering and retention topic. For telemetry, the common pattern is to move older raw parts to cheaper storage for a limited period and then delete them, while keeping aggregates on the hot volume for longer. Test the rules on a copy with representative ingestion rates, because a TTL that runs on a merge schedule frees space later than the calendar date suggests. Quality and traceability records are a different case. Batch genealogy, calibration history, alarm acknowledgements and operator changes may need longer retention or stronger protection than raw signals, and they may fall under a separate schedule that your quality function owns. Store them in their own tables, with their own TTL rules, access controls and backups, rather than letting them inherit the telemetry rules.
Retention periods come from your quality and regulatory obligations, such as product records, safety investigations and any sector rules that apply to your plants. DeployOpen does not set those periods. Ask your quality, legal and operations owners to write them down per data class before the schema is designed, and confirm that any deletion by TTL is covered by a backup or archive policy that meets the same schedule. Deleted telemetry cannot be recovered from ClickHouse after the rule runs, so check the restore procedure in the backup topic against each retention class.
Rollout from one pilot line to a multi-plant estate
The sequence moves ClickHouse from a scoped pilot on one production line to a replicated, restore-tested estate across plants without touching control networks before the design is agreed. Each phase closes with a written output that gates the next. Durations depend on plant count and integration scope and are confirmed in the written scope.
Inventory assets and scope with OT engineers
DeployOpen works with your OT engineers and plant managers to list the machines, PLCs, historians, gateways and message brokers that will feed ClickHouse, along with the signals, sample rates and the questions each team needs answered. Your side confirms which data is in scope, who owns each source and which data may leave a plant. The step closes with a signed inventory and a data flow diagram that names every producer, transport and consumer.
Design network zones and data paths
Using the inventory, the team places the ClickHouse nodes, Keeper nodes and ingestion components in zones that match your industrial security model, which is typically aligned with the ISA/IEC 62443 zone and conduit approach. Firewall rules, one-way or brokered paths from control networks, and time synchronization are specified here. The output is an approved zone diagram and a rule list that your network and OT security teams have reviewed.
Run the pilot line with representative load
The pilot covers one production line with the real ingestion path, table schemas, retention settings and the dashboards or queries operators actually use. DeployOpen measures sustained insert rate, peak bursts during shift changes or batch starts, query latency and disk growth against the data rates agreed in step one. The pilot closes when measured figures are recorded and the open questions about schema, partitioning and rollups are either resolved or assigned.
Validate the release in pre-production
Before the pilot results are carried forward, the chosen ClickHouse release is tested in a pre-production environment loaded with representative data and queries, as the project recommends. The team reads the changelog for backward-incompatible changes that could affect schemas, functions or ingestion, and records the upgrade decision. Confirm the release against the security policy's list of supported versions at the time of rollout. The output is a release record and a tested runbook.
Deploy replication and Keeper
Production replicas use ReplicatedMergeTree tables coordinated by ClickHouse Keeper, deployed on at least three dedicated Keeper hosts at the sizing given in the replication guide. DeployOpen configures the cluster layout, credentials, TLS and firewall rules from the approved zone design, then tests failover by stopping a replica and confirming that it resynchronizes from a healthy peer without manual steps. The step closes when the failover test passes and is documented.
Prove backups with restore tests
Backups run with BACKUP and RESTORE to storage you control, with full and incremental schedules set for the pilot tables. Replication does not protect against accidental deletes or corruption, so the team restores a copy of production data to a spare cluster and checks row counts, checksums and a sample of dashboard queries. The output is a restore report with measured recovery steps and a schedule for repeat restore tests.
Stage the rollout to further plants
Additional plants are added one at a time using the proven pattern, each with its own zone review, load measurement and restore check before it is connected to the central estate. Your site leads confirm local acceptance and the team updates the runbook with what each plant changed. The rollout is complete when every in-scope plant has a signed acceptance record, a tested restore and an owner for ongoing upgrades and monitoring.
Evidence manufacturers should prepare for OT and NIS2 reviews
OT and NIS2 reviewers rarely ask for a single document. They ask whether the telemetry path is separated from other networks, who can reach the data, whether restores have been proven, and whether the team can report an incident within the required timelines. The four areas below are the records to assemble before a review begins. DeployOpen prepares systems, controls and evidence for these reviews, but independent auditors and certification bodies issue any audit report or certification.
Segmentation and access records for the telemetry path
Keep a current diagram of every hop from PLC gateways and MQTT brokers through Kafka or collectors into ClickHouse, with the zone each component sits in and the firewall rules that permit each flow. Pair it with exported ClickHouse user, role and row policy definitions, and the network rules for ports 8123 and 9000. Reviewers will check whether the dashboards and BI tools that query plant data can reach only the segments they are meant to reach. Confirm these records against the live environment rather than the design document.
Authentication setup and default user lockdown
Record which external authenticator each user population uses, such as LDAP directories, Kerberos, X.509 certificates, an HTTP authenticator or JWT, and how service accounts for ingestion are issued. Show that the default user, which starts with all permissions, is restricted or disabled in each cluster. Keep the configuration files and a dated export of user lists so a reviewer can compare what is documented with what is running.
Backup and restore test records
A backup configuration is weak evidence on its own. Keep the BACKUP schedule, the storage destination, and a log of restore tests run on a spare cluster, including the date, the tables restored, row counts compared and any failures and fixes. The ClickHouse documentation warns that a backup never test-restored will probably not restore properly when needed, and replication alone does not protect against human error or corruption. Reviewers will look for these restore records as much as for the backups themselves.
Incident reporting readiness under NIS2
Under NIS2, significant incidents at in-scope entities must be reported with an early warning within 24 hours, a notification within 72 hours and a final report within one month. Prepare a runbook that names who decides an incident is significant, which logs and ClickHouse system tables are preserved, and how the early warning is drafted and sent. Run a tabletop exercise against a telemetry-loss scenario and keep the minutes. Confirm with counsel which national authority applies to your entity.
Questions manufacturers ask before scoping a ClickHouse telemetry build
What drives the cost and effort of a plant deployment?
The main drivers are the number of plants, the data rate from each one, the number of integrations, and the time needed for OT access reviews. Each plant adds its own network paths, tag mappings and ingestion checks, so effort grows with the plant count even when the ClickHouse design is shared. Higher data rates raise the sizing of Keeper, storage and ingestion capacity. Your quote should break these out separately: design, build per plant, integration work, access review support, and any recurring support. Ask for the assumptions behind each line so you can see which change would move the price.
How long does a ClickHouse telemetry build take, and what sets the timeline?
The timeline depends mostly on how quickly the OT inputs arrive and how many plants go live. Access reviews with plant and security teams, the availability of change windows, and the agreement on tag lists often take longer than the ClickHouse work itself. A single pilot plant with a defined schema moves faster than a multi-site rollout that needs a repeatable pattern. Because most engagements are fixed-scope, the written plan should set milestones and the inputs each milestone depends on. Ask for those dependencies explicitly before accepting any date.
What must our team provide before the work starts?
Expect to provide the following before design begins:
- OT network diagrams showing the zones, conduits and the points where telemetry leaves each plant
- Tag lists with units, sampling rates and naming conventions for each asset
- Named data owners who can approve schemas, retention periods and access rules
- Change windows on plant networks and on the Kafka or MQTT brokers
Missing any of these delays the build, and changes to tag lists after schema design usually mean rework. Confirm the format and owner of each item in writing at the start.
Can our internal team run a ClickHouse telemetry platform alone?
A capable internal team can run it, but it needs skills across several areas: Linux and Kubernetes or package-based operations, ClickHouse replication and Keeper administration, Kafka operations, backup and restore testing, and security administration for both IT and OT zones. The ClickHouse replication documentation recommends at least three Keeper nodes on dedicated hosts in production, and the backup documentation advises regular restore tests on spare clusters. Assess your team against that list honestly. Many organizations split the work, keeping day-to-day operations in-house and buying design, hardening or upgrade support.
How are ClickHouse upgrades handled given the supported version list?
Upgrades follow the supported-version list in the ClickHouse security policy and the changelog. The policy currently lists versions 26.9, 26.8, 26.7 and 26.3 as receiving security updates, and all other versions are 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 every upgrade because minor backward-incompatible changes can occur. Plan a staging cluster that receives the same telemetry, test your rollups and queries there, and schedule production upgrades inside agreed change windows. Confirm with your provider how the upgrade cycle is covered in the support model.
Which Kafka version and security settings affect the telemetry pipeline?
Kafka version choice affects your broker and client requirements. Kafka 4.0 and later run only in KRaft mode, so ZooKeeper-based clusters must migrate first, and the upgrade notes recommend moving KRaft clusters older than 3.3.x to 3.9.x before 4.x. Brokers and Kafka Connect require Java 17 from Kafka 4.0. On security, Kafka supports SSL or SASL, with GSSAPI, PLAIN, SCRAM-SHA-256, SCRAM-SHA-512 and OAUTHBEARER as documented SASL mechanisms. Security is optional, so confirm that every plant listener is encrypted and authenticated, and that KRaft ACLs deny access to resources without rules. Check the supported releases on the Kafka downloads page before you choose a version.
What OT security standards should the design account for?
The ISA/IEC 62443 series is the main reference for securing industrial automation and control systems, and NIST SP 800-82 Rev. 3 covers OT security more broadly. Asset owners generally need a security program and a risk assessment for system design, and the telemetry path should be treated as a conduit between zones. ClickHouse design should therefore keep plant-facing ingestion separate from analytics users, and record which zone each data flow crosses. Ask your auditor or OT security lead which requirements apply to your sites before the design is frozen.
What to ask a partner before signing a telemetry scope
Start with the OT boundary, because every other answer depends on it. Ask the partner to show, in a written network zone diagram, where the ClickHouse servers, the Keeper nodes, the Kafka or MQTT brokers and the ingestion connectors sit relative to the control network and the DMZ, and which flows cross each boundary, in which direction and on which ports. Ask who approves each flow and how the design maps to the zone and conduit model in ISA/IEC 62443. The deliverable to request is the diagram, the flow register and a list of the firewall rules that will be created, reviewed by your OT security owner before any build starts.
Next, ask how failures are handled at each stage of the pipeline. For Kafka, ask which replication factor and min.insync.replicas values are proposed, how a broker outage affects the buffering on the plant side, and how consumer offsets are tracked so that data is not lost or double-counted after a restart. For MQTT, ask how the bridge reconnects, what happens to messages published while it is down, and whether the design depends on broker-side persistence. Ask for a written failure test plan that covers a broker loss, a network partition between the plant and the data center, and a ClickHouse replica outage, with the expected result for each. Also ask how restore tests are scheduled: the ClickHouse backup documentation advises regular restore tests on spare clusters, so request a dated test calendar, the restore target, and the evidence each test produces.
Finally, ask how upgrades are staged and what remains after go-live. Request a written upgrade plan that moves one plant at a time through a test cluster, with the ClickHouse release chosen from the supported line listed in the ClickHouse security policy, and that reads the changelog before each change. Confirm what support is retained after go-live: who responds to a Keeper quorum loss, who owns the runbooks, and whether the contract includes a retainer for upgrades and restore testing. The handover package should contain the runbooks, configuration in version control, backup and restore procedures, and a named support contact. Confirm each of these in writing before signing.
What the client receives and runs after go-live
The handover turns the build into something your own team can run, change and recover without depending on the implementation partner for routine work. Each item is delivered in writing, tested where it matters, and tied to the operating model agreed before go-live.
Document schemas and rollup definitions
DeployOpen delivers the table definitions for raw telemetry, the ordering and partition keys, the ingestion path from Kafka or MQTT, and each materialized view or rollup with its source, grain and retention. Your data engineers review the documents against the running cluster, and the handover closes when every table and rollup in production matches its written definition. This is a one-time deliverable that your team updates through change control as new asset types or sensors are added.
Write runbooks for ingestion lag
The runbook covers how to read consumer lag on the Kafka topics, how to tell whether the bottleneck sits in the broker, the consumer or the ClickHouse insert path, and which steps to take for a stalled plant feed. It names the owner for each step and the escalation route to the plant network team. DeployOpen tests the runbook against a simulated lag event in the pre-production environment, and the step closes once your on-call staff have run it themselves.
Write runbooks for Keeper health
ClickHouse replication depends on ClickHouse Keeper, and the Keeper runbook covers quorum checks across the at least three Keeper nodes that the replication guide recommends on dedicated hosts, along with what to do when a node is lost and how to confirm that replicas resynchronize. The guide notes that a recovered replica automatically syncs missing data from a healthy replica, and the runbook explains how operators confirm that sync has finished. Your team signs off on the runbook after a controlled node restart in the test environment.
Hand over backup and restore procedures
DeployOpen documents the scheduled BACKUP jobs, their destination, retention settings and the RESTORE steps for a table, partition or database. Backups are not considered delivered until a restore has been performed on a spare cluster, because the ClickHouse backup documentation warns that a backup never test-restored will probably not restore properly when needed. The handover record includes the date of the restore test, the recovered row counts and the named owner of the restore drill.
Document the access model
The access documentation lists the users, roles, row policies, settings profiles and quotas for ingestion services, plant engineers, analysts and administrators, along with the external authenticator choice, such as LDAP or JWT, that your directory supports. It records that the default user has been restricted, as the access control documentation recommends. Your security team reviews the matrix against your plant and corporate identity groups, and the item is complete when each role maps to a named group and no account holds more permissions than its role requires.
Agree the upgrade plan
The upgrade plan states which ClickHouse release line you run, whether stable or LTS, and how it moves across replicas in rolling order with a pre-production test using representative data and queries first. It references the security policy's list of supported versions and the changelog review step before each move. Your team and DeployOpen agree the calendar and rollback steps in writing, and the plan is accepted when the first upgrade has been rehearsed in the test environment.
Confirm ongoing support options
After handover, your team owns routine operations such as change control, capacity checks, restore drills and runbook maintenance. Ongoing support, upgrades and continuous testing are available as a retainer, which is scoped and priced separately from the fixed-scope build. Ask for the retainer scope in writing, including who responds to plant-level incidents and how restore drills and upgrades are scheduled, so the recurring work is visible before go-live closes.
How DeployOpen works on this
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including ClickHouse for manufacturing and IoT telemetry. We start from written scope, build the ingestion, schema and retention design against your plant and network constraints, and hand over a system your engineers can operate.
How we scope
- Written scope covers telemetry sources, protocols, message volumes and the plants or sites involved.
- Scope lists the Kafka or MQTT ingestion path, table design, rollup and retention rules, and tiers.
- Scope names the networks, zones and hosts where ClickHouse runs, and the access model for each team.
How we build
- We build ingestion and schemas in a pre-production environment fed with representative sensor data.
- We configure ReplicatedMergeTree tables, ClickHouse Keeper nodes and tiered retention, then test them.
- We run BACKUP and RESTORE tests on a spare cluster and record the results in the handover.
How we hand over
- Handover includes configuration, runbooks, architecture notes and the ingestion and retention decisions made.
- Your engineers get documented procedures for replica recovery, version upgrades and restore testing.
- Access controls, external authenticator setup and TLS settings are documented for your security review.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainer work can cover reviewing ClickHouse release notes and planning upgrades before each change.
- Confirm with us during scoping which support hours, response paths and escalation terms apply.
