Why self-hosted product analytics changes once event volume grows
A self-hosted PostHog or OpenReplay pilot that runs well on one virtual machine does not prove it will run at production volume. The scaling question is less about the software working and more about whether the team can keep event ingestion, storage, replay retention and upgrades within its own capacity. PostHog's README says open-source deployments should scale to approximately 100k events per month and recommends moving to PostHog Cloud above that level. Its self-host documentation also states that self-hosted deployments are officially unsupported and that PostHog does not offer customer support for product or infrastructure questions on them. Before a pilot becomes a system of record, the team should measure its real monthly event count, not the count it expected, and decide who answers for the stack when it fails.
The short answer on platform choice is this. PostHog fits event-heavy product analytics, where funnels, retention and feature flags depend on high event throughput. OpenReplay fits replay-centric work, where session recordings, DevTools data and capture-time masking matter most. When event volume, identified-user growth or replay retention outgrows the team's operations capacity, a managed service or a warehouse-based design becomes the better option to evaluate. Confirm with each vendor which edition, license terms and support scope apply to your deployment, since PostHog's paid features in its ee/ directory require a PostHog license on a self-hosted instance.
Replay retention is the volume driver teams most often underestimate. OpenReplay's own deployment guidance starts a single VM with 2 vCPUs, 8 GB of RAM and 50 GB of storage, which is a starting point for a pilot, not a sizing for production traffic. Ask your team to model storage per day of recorded sessions, the retention period you must support, and the growth in identified users. Then compare that model with the OpenReplay deployment documentation and decide whether your own infrastructure team can absorb the growth, or whether a managed option removes that operational load.
Which requirements appear when volume grows
This table compares the requirements that appear as event volume rises, across PostHog sizing guidance, ClickHouse operations and OpenReplay storage. Read each row as a question to answer before the build starts, not after the first data loss or outage. The main takeaway is that the hobby reference sizing is a starting point, and the operational work begins well before the platform is full.
| Requirement | Source | What it means for the build |
|---|---|---|
| Event volume and sizing | PostHog README | PostHog says open-source deployments should scale to about 100k events per month and recommends its cloud service above that. Plan your migration trigger in advance. |
| Hobby reference server | PostHog self-host docs | The free Docker Compose hobby deployment cites 4 vCPU, 16 GB RAM and more than 30 GB storage. Treat this as a floor for evaluation, not a production sizing. |
| ClickHouse replication and Keeper quorum | ClickHouse docs | Replicated tables are coordinated by ClickHouse Keeper. Run at least three Keeper nodes on dedicated hosts, each with about 4 GB RAM, and confirm the quorum design with your platform team. |
| Backup and restore testing | ClickHouse docs | Replication does not protect against human error or corruption. Schedule BACKUP and RESTORE tests on a spare cluster, since an untested backup may not restore when needed. |
| ClickHouse version support windows | ClickHouse security policy | Only listed versions receive security updates. Confirm which release line you run, and budget for regular upgrades after reading the changelog. |
| Authentication via external authenticators | ClickHouse docs | ClickHouse supports LDAP, Kerberos, SSL X.509, HTTP authenticators and JWT. Pick the method that matches your directory and confirm it with your identity team. |
| OpenReplay storage and retention | OpenReplay README | A single VM with 2 vCPUs, 8 GB RAM and 50 GB storage is the starting point. Storage grows with recorded sessions, so set retention and capacity alerts before launch. |
| PostHog Cloud pricing and plan thresholds | PostHog pricing | The first 1 million events per month are free on cloud, and retention and project limits differ by plan. Compare these thresholds with your projected volume before deciding to self-host. |
Which scaling path fits which team
Staying self-hosted on PostHog keeps every event in your own infrastructure, with ClickHouse as the analytics store behind the product. The core repository is MIT licensed, but the ee/ directory is covered by a separate license, and premium features from that directory require a PostHog license on a self-hosted instance. Teams that need fully free software can look at the posthog-foss repository, which removes all proprietary code and features.
- Licence limit: Confirm which features your plan needs and whether they sit in
ee/, because a required premium feature changes the licence you need. - Support owner: PostHog states that self-hosted deployments are officially unsupported, so your platform team or implementation partner carries upgrades, incidents and troubleshooting.
- Volume ceiling: The README says open-source deployments should scale to about 100k events per month and recommends PostHog Cloud above that level.
- Kubernetes: PostHog's self-host docs note that new Kubernetes deployments of its paid self-hosted product are no longer supported, so check the deployment target before you design around it.
Before committing, confirm the expected monthly event count, the licence features you need and who holds the pager for the ClickHouse layer.
Self-hosting OpenReplay suits teams where session replay, DevTools data and console logs matter as much as funnels. The monorepo is licensed under AGPLv3, some directories are MIT, and everything under ee/ falls under a separate commercial license, so the licence you accept depends on which directories you deploy and modify. Self-hosting keeps session data in your infrastructure, and first-party tracking from your own domain is not blocked by ad blockers.
- Licence limit: AGPLv3 obligations can apply when you modify and offer the software over a network, so review the terms with counsel before changing the code.
- Support owner: The open-source edition runs on community support and self-managed retention, so your team or partner owns operations, backups and upgrades.
- Starting footprint: The README says one VM with 2 vCPUs, 8 GB of RAM and 50 GB of storage is enough to start, but replay storage grows with traffic and retention.
- Storage and retention: Replay volume, not event count, usually sets the storage plan, so model recordings per session and retention before sizing disks.
- Enterprise features: SSO, SCIM, audit trail and a custom SLA sit in the self-hosted Enterprise edition on custom terms.
Check the replay sessions per month, the retention period and the licence scope before you choose this path.
OpenReplay offers managed options that keep the product in a vendor-operated or shared-responsibility model. OpenReplay Dedicated is a fully managed instance starting at $199 per month on AWS, GCP or Azure with a 7-day trial, as listed on the pricing page. Bring-Your-Own-Cloud runs in your own cloud account on AWS, GCP or Azure, which keeps data in your accounts while the vendor helps operate the stack.
- Pricing source: The $199 per month starting point comes from the OpenReplay pricing page, and the quote for your volume will differ.
- Support owner: The vendor operates Dedicated, while BYOC splits responsibilities, so put the division of duties in writing.
- Data location: Dedicated runs in the regions the vendor lists, so confirm the region and sub-processors against your data residency rules.
- Volume ceiling: Confirm with the vendor how the plan scales with replay sessions and retention, since the public page does not set an event ceiling for your case.
- Exit path: Ask how data exports and migration back to self-hosting would work if you change direction.
Ask for the contract terms on support, regions and data deletion before you rely on this path.
PostHog Cloud removes server operations from your team and offers two hosting regions, US (Virginia) and EU (Frankfurt). The Free plan includes 1 project, 1-year data retention and the first 1 million analytics events free each month. The Pay-as-you-go plan raises this to 6 projects and 7-year data retention. SSO, audit logs, custom roles and project permissions are sold as platform packages.
- Region choice: Pick US (Virginia) or EU (Frankfurt) when you sign up, and confirm where session data and sub-processors sit.
- Retention: Retention differs by plan, so match the period to your privacy policy and records of processing.
- Access controls: Identity and access features are sold as platform packages, so budget for them if you need SSO or audit logs.
- Migration: Managed migrations can import historical events from Mixpanel or Amplitude, but each direct import covers at most one year and is not deduplicated.
- Deletion: Imported event data cannot be selectively deleted, so test the import on a sample first.
Confirm the region, retention and package features with PostHog before you move production traffic.
A warehouse-based design sends events through an open-source pipeline into ClickHouse, then models funnels and retention in SQL and shows results in a BI tool. ClickHouse server is licensed under Apache-2.0, and ClickHouse Inc. sells a managed service separately. This path gives your data team full control of the schema, but it moves the product analytics UI, identity and tracking SDK work onto your team.
- Replication: ReplicatedMergeTree tables use ClickHouse Keeper, and the replication guide recommends at least three Keeper nodes on dedicated hosts in production.
- Backups: Replication does not protect against human error or corruption, so plan BACKUP and RESTORE with regular restore tests on a spare cluster.
- Upgrades: Support covers versions 26.9, 26.8, 26.7 and 26.3 for security updates, so schedule upgrades before a line goes unsupported.
- Authentication: LDAP, Kerberos, X.509 certificates, HTTP authenticators and JWT are supported as external authenticators.
- Ownership: Your team owns the pipeline, dashboards and experiment analysis, which usually makes this the highest internal staffing load.
Confirm the staff who will own the pipeline and the restore testing schedule before you choose this design.
How a scaling rollout moves from pilot to production
This sequence takes a self-hosted product analytics stack from a measured baseline to a production cluster that has been restored from backup and load tested, with a named support model before cutover.
Establish the volume and retention baseline
The client team and DeployOpen measure current and projected event volume, session replay volume, peak ingestion rates, query patterns and the retention each data class requires. Retention is set per data type, because a legal or internal rule may differ for events, recordings and identifiers. The output is a written baseline with a decision on whether self-hosting still fits. PostHog's README says open-source deployments should scale to approximately 100k events per month and recommends its cloud service above that, so a baseline above that level should trigger a formal comparison with managed options before any build starts. Gate: sign-off on volume, retention and the hosting decision.
Size the cluster and select supported versions
DeployOpen turns the baseline into sizing for ClickHouse, the application tier, storage and the replay storage that OpenReplay requires, and selects a ClickHouse release from the lines the project lists as supported with security updates. Teams should prefer a supported stable line for most production use or an LTS line where their change control requires it, and confirm both choices against the current ClickHouse security policy on the day of selection. Sizing is validated in a pre-production environment loaded with representative data and queries. Output: a sizing record and a version pin. Gate: pre-production benchmarks meet the agreed query and ingestion targets.
Build replication with ClickHouse Keeper
DeployOpen builds ReplicatedMergeTree tables coordinated by ClickHouse Keeper, which replaces ZooKeeper. The ClickHouse replication guide recommends at least three Keeper nodes on dedicated hosts in production, each with about 4 GB of RAM. The team tests failure cases by stopping a replica and confirming that, once it recovers, it syncs missing data from a healthy replica without manual intervention. Output: a documented topology and a recorded failover test. Gate: a replica failure and recovery test completes with no data gaps in the test dataset. Replication is treated as availability protection only, since it does not protect against human error or corruption; that is the job of the next phase.
Configure authentication and access
DeployOpen connects ClickHouse to the client's identity source using the external authenticators the product supports, such as LDAP, Kerberos, SSL X.509 certificates, an HTTP authenticator or JWT authentication, and defines roles so analysts, engineers and administrators see only the data they need. Access to session recordings is restricted separately from event access. Output: a role matrix, a tested login path for each authentication method and a list of service accounts with owners. Gate: access reviews confirm that no shared administrative account is used for routine analysis, and that the client's security team has approved the matrix.
Run backups and timed restore tests on a spare cluster
DeployOpen configures ClickHouse BACKUP jobs for full and incremental backups to the storage the client selects, which may be local disk, S3-compatible storage or Azure Blob Storage. The ClickHouse documentation warns that a backup never test-restored will probably not restore properly, so the team restores a copy into a spare cluster, records how long each restore took, and checks row counts and sample queries against the source. Output: a restore runbook with measured restore times and a signed test record. Gate: the restore completes, the data matches, and the client accepts the recovery time that the test produced.
Cut over and load test the production path
DeployOpen moves ingestion from the pilot to production, starting with the SDKs that send the highest volume. Before full traffic, the team runs load tests at the peak rates from the baseline and at a margin above them, watching ingestion lag, query latency and disk growth. The cutover plan defines the rollback step and who can trigger it. OpenReplay and PostHog SDK settings for masking are re-checked at this stage, so recordings are not captured with unmasked data under production traffic. Output: a load test report and a cutover record. Gate: load tests pass the agreed targets and the rollback path has been rehearsed.
Agree the support model before go-live
The client and DeployOpen agree who runs the stack after cutover, which tasks belong to the client's platform team, and which belong to DeployOpen under a retainer or a separate written scope. PostHog's documentation states that self-hosted deployments are officially unsupported and that PostHog does not offer customer support for infrastructure questions on self-hosted instances, so the client must confirm who covers upgrades, security patches and incident response for each component. Output: a responsibility matrix, an upgrade calendar tied to supported ClickHouse lines and an escalation path. Gate: both parties sign the matrix, and the first scheduled restore test is booked into the operating calendar.
Which integration points carry the most load
As event volume grows, load concentrates in a few places: how events reach the server, how ClickHouse replicates and recovers, how the cluster coordinates, where backups land, who can sign in, and how replay storage is pruned. Each card below names one of these points, the risk it creates and what to confirm before you size the platform.
SDK and first-party ingestion path
Every event passes through the browser or mobile SDK and the ingestion endpoint before it reaches storage. A self-hosted deployment serves that endpoint from your own domain, so the proxy, load balancer and TLS termination in front of it set the ceiling on throughput. Check batching and retry behavior in the SDK, how the ingestion tier scales horizontally, and what happens to buffered events during an outage. Ask your implementation partner to load test with production event shapes, not synthetic single events.
ClickHouse replication
ReplicatedMergeTree tables keep copies of event data on more than one replica, so a single node failure does not stop reads or writes. Replication does not protect against human error or corruption, because a bad delete or a faulty deployment is copied to every replica. Confirm the replica count per shard, the number of shards you need at target volume, and how much disk and network bandwidth each replica consumes during merges and resyncs.
Keeper coordination
ClickHouse Keeper coordinates replicated tables and replaces ZooKeeper in this role. The replication guide recommends at least three Keeper nodes on dedicated hosts in production, each with about 4 GB of RAM. Keeper is small in resources but sensitive to disk latency and to co-location with busy analytics nodes, and losing quorum stalls replicated writes. Confirm that Keeper nodes sit in separate failure domains and that your monitoring alerts on Keeper health separately from ClickHouse itself.
Object storage for backups
BACKUP and RESTORE write full and incremental backups to local disk, S3-compatible storage or Azure Blob Storage. Backup volume grows with event history, so storage cost and backup window grow with it. The ClickHouse documentation warns that a backup never test-restored will probably not restore properly, so schedule restores to a spare cluster and record how long they take. Confirm the target bucket's immutability and access controls, the retention policy for backups and the restore time your analysts can tolerate.
Identity and external authenticators
ClickHouse can delegate login to LDAP, Kerberos, SSL X.509 certificates, an HTTP authenticator or JWT, and access rights are defined per user and role. At higher volume, more services and analysts query the cluster, so shared accounts and broad grants become both a security and a performance problem. Confirm which authenticator your identity provider supports, how service accounts for the ingestion tier are scoped, and whether query quotas exist for ad hoc analyst queries.
Retention jobs for replays
Session replay storage grows faster than event tables because each recording carries DOM and network data. Retention is what keeps that growth bounded, and OpenReplay lets you set self-managed retention in the open-source edition. Confirm how expired recordings are deleted, whether deletions run on a schedule that your storage budget assumes, and that deletion also covers backups and object storage copies. Ask the vendor how retention interacts with the privacy commitments you have made to users.
What buyers ask before scaling self-hosted analytics
What does it cost to run self-hosted product analytics at higher event volumes?
Self-hosting has no vendor license fee for the open-source core, so the costs are infrastructure, implementation, and internal staff time. Infrastructure is recurring and grows with event volume, retention and replay storage. Implementation and hardening are one-time, though upgrades, backups and restore tests recur. PostHog's README says open-source deployments should scale to approximately 100k events per month and recommends its cloud service above that, and its pricing page says the first 1 million analytics events are free each month on its managed plans. Ask any implementation partner for a written quote that separates one-time setup from monthly hosting, storage and support, and that states which volume and retention assumptions it uses.
How long does it take to move a self-hosted analytics pilot into production?
The duration depends mainly on the number of event sources, the depth of data governance, and how much of the stack must be hardened before real traffic arrives. No timeline is set by a researched fact, so confirm one in the written scope. The main drivers are the tracking plan and its review, masking rules for session replay, identity and access setup, the sizing and load test of the ClickHouse cluster, backup and restore testing, and the cutover of SDKs in production applications. Each of these can be scheduled independently, so ask the partner to list them as separate deliverables with their dependencies.
What must our team provide before a self-hosted analytics rollout starts?
Your team must provide the infrastructure account or data center access, a named owner for the analytics data, and the people who can approve tracking events and masking rules. Self-hosted deployments are officially unsupported by PostHog, which does not offer customer support for infrastructure questions on self-hosted instances, so an internal or contracted operations function has to own the stack. Plan for on-call coverage, a patching routine, and a documented restore procedure. Ask the partner to confirm which of these responsibilities they will carry under a retainer and which stay with your staff.
Can we run a self-hosted analytics platform without an implementation partner?
Yes, many teams do, provided they have engineers who can operate Docker or Kubernetes, a ClickHouse specialist for the analytics database, and someone who owns the security review. The open-source PostHog hobby deployment is installed with a deploy script, but production use at volume needs more than that install. OpenReplay's README says a single virtual machine with 2 vCPUs, 8 GB of RAM and 50 GB of storage is enough to start self-hosting, which is a starting point, not a production sizing. Be honest about whether these skills exist in-house before you commit, and ask a partner to scope a fixed review of your current setup if you are unsure.
When should we move to PostHog Cloud or OpenReplay Dedicated instead?
Move to a managed service when operating the stack costs more in staff time and risk than the subscription, or when event volume and retention outgrow what your team can sustain. PostHog's README recommends its cloud service above about 100k events per month. OpenReplay's pricing page lists OpenReplay Dedicated as a fully managed instance starting at $199 per month on AWS, GCP or Azure, with a 7-day trial. Before deciding, compare data location, since the managed options may place data in regions you have not approved, and check whether single sign-on, audit logs and custom roles are included at your tier, because PostHog sells these as platform packages.
How do ClickHouse upgrades and LTS releases affect operations?
ClickHouse ships stable releases roughly monthly and LTS releases twice a year, with each LTS supported for one year after release. The ClickHouse security policy lists 26.9, 26.8, 26.7 and 26.3 as supported with security updates, so any other version needs an upgrade plan. For most production use, ClickHouse recommends stable releases after testing in a pre-production environment with representative data and queries. Choosing an LTS line trades newer features for a longer, predictable patch window. Read the changelog before each upgrade, because minor backward-incompatible changes can occur. Schedule upgrades as recurring work in your operations budget.
How should we protect and restore analytics data as volume grows?
Replication protects against hardware failure, but it does not protect against human error or corruption, so you also need backups. ClickHouse BACKUP and RESTORE supports full and incremental backups to local disk, S3-compatible storage or Azure Blob Storage. ClickHouse's own documentation warns that a backup never test-restored will probably not restore properly, and it recommends regular restore tests on spare clusters. Replication coordination uses ClickHouse Keeper, which the replication guide recommends running as at least three nodes on dedicated hosts with about 4 GB of RAM each. Ask your partner to include restore tests and the Keeper topology in the written scope.
What to ask an implementation partner about scale
Scale problems rarely show up in a demo. They show up when event volume, replay storage and restore needs grow after go-live, so the questions below focus on evidence, recovery, upgrades and the written terms that govern them. Use them to compare partners before any scope is agreed.
Sizing evidence and load tests
Ask for the sizing method behind the proposed servers, storage and ClickHouse layout, and for the event volume and query mix it was tested against. PostHog's README says open-source deployments should scale to about 100k events per month, so ask at what volume the partner expects the design to be re-sized and who measures it. Ask for the storage growth estimate for OpenReplay session data at your retention setting, and whether the partner will run a load test with your own event schema before production.
Restore testing and backup evidence
ClickHouse's backup documentation warns that a backup never test-restored will probably not restore properly, and that replication does not protect against human error or corruption. Ask who runs restore tests, how often, on which spare cluster, and what recovery time and data loss the partner has measured. Ask whether backups cover ClickHouse tables, OpenReplay storage and configuration, and where the copies are kept inside your own infrastructure.
Version and upgrade policy
ClickHouse publishes stable releases roughly monthly and supports only a small set of versions with security updates, while LTS lines ship twice a year. Ask which ClickHouse line the partner will run, who tracks support windows, and how upgrades are staged through a pre-production environment with representative data. Ask how OpenReplay and PostHog upgrades are handled and whether a rollback path is documented for each.
Licence and edition fit
PostHog's README says premium features in the ee/ directory require a PostHog license on a self-hosted instance, and OpenReplay's ee/ directory sits under a separate commercial license. Ask the partner to list every component and feature in the design, mark which fall under ee/ or other proprietary terms, and state which edition they will deploy. Ask who holds the licence relationship and what it costs to scale past the free tier.
Support after go-live
PostHog states that self-hosted deployments are officially unsupported and that it does not provide customer support for infrastructure questions on self-hosted instances. Ask who answers incidents at 2 a.m., who owns the ClickHouse Keeper nodes, and what response times the partner commits to in writing. Ask whether support covers ClickHouse, the analytics application and the reverse proxy as separate responsibilities.
Fixed scope and retainer terms
Most DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support, upgrades and testing are available as retainers. Ask the partner to define which event volume, session volume and retention period the fixed scope covers, and what triggers a change request when volume grows. Ask what the retainer includes on upgrades, backups and restore tests, and how it is priced against the written scope.
Where a fixed-scope engagement helps at scale
A fixed-scope engagement helps most when the question is no longer whether self-hosting works but who owns the cluster once event volume outgrows the hobby setup. DeployOpen plans, implements, customizes, hardens, backs up, upgrades and documents self-hosted platforms inside your own cloud accounts, data centers or air-gapped networks, so the stack that takes over from a single Docker Compose host stays in your environment. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, which lets you hold the work to named items such as a ClickHouse topology, a backup job with a documented restore test, or an OpenReplay storage and retention policy.
Scope at this stage needs specific decisions. Ask for written answers on how ClickHouse Keeper nodes are placed and sized, how replicas are checked after recovery, who runs the restore test described in the ClickHouse backup documentation, and which OpenReplay retention settings apply to each recording class. PostHog states that self-hosted deployments are officially unsupported and that it offers no customer support for infrastructure questions, so the operating model has to be written into the statement of work rather than assumed. Ongoing support, upgrades and continuous testing run as retainers, and a retainer should name the ClickHouse release line you will follow and who approves each upgrade.
DeployOpen does not publish prices, and a quote follows from the written scope. To compare quotes, require each one to list the components in scope, the environments covered, the handover documents, the test evidence delivered, and which items are one-time and which recur under a retainer. Quotes that leave these lines out are hard to compare, whatever the total. Where the volume case points toward a managed service or a warehouse-based design, the same written scope should say so, so the decision is made on evidence rather than on the cost of the first build.
Which evidence supports a scaled analytics stack
This table maps each piece of evidence an assessor or internal reviewer will ask for to the component that produces it and the person who should review it. Use it to plan what gets logged and retained from day one, not after a scale-up. DeployOpen prepares this evidence for your compliance assessments, but it does not issue audit reports or certifications, which independent auditors and certification bodies provide.
| Evidence item | Which component produces it | Who reviews it |
|---|---|---|
| Sizing and load test records | Event pipeline benchmarks, ClickHouse query timings and ingestion tests run against your expected monthly event volume | Platform engineering lead and the data owner who signed off the capacity plan |
| ClickHouse version and support status | Installed server version compared with the published security policy and the production release guidance | Security engineering and the platform team responsible for patching |
| Backup job logs and restore test results | ClickHouse BACKUP and RESTORE job logs, plus records from restores run on a spare cluster | Operations lead, with the data protection owner reviewing restore outcomes |
| Access and authentication configuration | External authenticator settings (LDAP, Kerberos, SSO or JWT where used), user roles and database grants | Identity and access team, reviewed against the joiner, mover and leaver process |
| Retention settings for events and replays | Configured retention in the analytics platform and the storage lifecycle or deletion jobs for ClickHouse and object storage | Privacy or compliance lead, against the records of processing and retention schedule |
| Change records for upgrades | Pre-production test results, changelog review notes and approval tickets for each platform and ClickHouse upgrade | Change advisory board or the service owner who approves production changes |
How DeployOpen scopes and supports scaled product analytics
DeployOpen plans, implements, hardens, documents and supports self-hosted analytics inside your own cloud accounts, data centers or air-gapped networks. For teams moving past hobby event volumes, the work starts with a written scope that sets the event load, the ClickHouse and storage design, the retention rules and the point where a managed service or warehouse design makes more sense.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- We size current and projected monthly event volume, replay volume and retention periods against the stack you intend to run.
- We document which tier fits each workload: a single self-hosted deployment, a scaled ClickHouse cluster, or a managed service.
How we build
- We deploy PostHog or OpenReplay in your environment, with ClickHouse sized and replicated to match the agreed event load.
- We configure ClickHouse Keeper with dedicated nodes, replication and capture-time masking settings as the written scope defines.
- We test ingestion under representative event load and query performance before any production traffic is routed to the stack.
How we hand over
- You receive architecture, runbooks for upgrades, backups and restore tests, and the retention and masking configuration as documented records.
- We run a backup and restore test on a spare cluster and document the results, since untested backups often fail when needed.
- Handover covers which edition, license terms and feature packages are in use, so your team can confirm obligations after go-live.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the build.
- Upgrades follow the ClickHouse supported release lines and a pre-production check against representative data before each change.
- Ask any implementation partner to confirm in writing which support, response and SLA terms apply to your scope.
