ClickHouse vs PostgreSQL: which to choose

When to choose ClickHouse, when to choose PostgreSQL, and what decides it

PostgreSQL remains the right choice for transactional workloads, and ClickHouse is not a replacement for it. The situation this section addresses is common: a PostgreSQL system serves orders, accounts or case records, and reporting queries that scan large tables run on the same primary and slow down the writes and short lookups the business depends on. Moving those scans to ClickHouse fits large scans, aggregations and many-user analytics, where a columnar engine reads only the columns a query needs. It does not fit row-level updates, frequent single-row reads or workloads where the application expects strict relational constraints on every write. Before deciding, separate the workloads. Ask which queries scan millions of rows, how often data changes after it is written, and whether the same records must be read and updated within one transaction.

Five drivers decide the split. The first is query shape: grouped aggregations over wide time ranges favor ClickHouse, while lookups by primary key favor PostgreSQL. The second is data volume and growth, since the point at which scans hurt PostgreSQL depends on your hardware and indexes, so measure it on your own tables rather than assuming a threshold. The third is update patterns: append-heavy event data suits a column store, while data that is edited in place often does not. The fourth is team skills, because your engineers already know PostgreSQL operations, backup tooling and SQL dialect, and ClickHouse adds its own table engines, replication model and backup procedures. The fifth is operational load: a second database means a second backup scheme, monitoring, upgrade calendar and on-call runbook. Confirm the current ClickHouse release and support status with the ClickHouse documentation before you commit, and plan a restore test on a spare system before relying on either platform for analytics.

Which database fits which analytics scenario

This table maps common scenarios from your own system to the database that fits better, with the condition under which the other choice wins. Read it by finding the row closest to your workload, then check the conditions before committing.

Scenario	Better fit	Reason	When the other database wins
OLTP application backend with single-row reads and writes	PostgreSQL	Row storage and transactional updates are its core design, and it supports hot standbys and synchronous replication for the application's write path.	Rarely a fit for ClickHouse as a primary store, since single-row retrieval is slower in column storage.
Dashboards over large fact tables with wide aggregations	ClickHouse	Column storage speeds filtering and aggregation across many rows, which is the shape these dashboards query.	Small tables or modest query volumes where PostgreSQL indexes and existing tooling already meet the latency target.
Event and log analytics with high append volume	ClickHouse	Append-heavy, scan-heavy queries over time ranges match the column store model, and ClickHouse is built for online analytical processing.	When events are few, retention is short, and a single PostgreSQL instance already answers queries within your limits.
Frequent single-row lookups and updates on the same records	PostgreSQL	Row-level updates and point lookups are the workload PostgreSQL handles natively, with transactions across related tables.	Only when the lookups are really analytical scans; confirm query shapes with your own workload before deciding.
Reporting that joins many normalized OLTP tables on demand	PostgreSQL first	Joins across operational tables are easier to keep consistent when the data stays in one transactional system.	When joins are wide, repeated and slow in PostgreSQL, a denormalized ClickHouse table may be the better analytics copy.
Small team running one database with limited operations staff	PostgreSQL	One engine, one backup routine and a long support window per major version reduce moving parts.	When the analytics workload is large enough that PostgreSQL tuning stops meeting targets and the team can run a replicated ClickHouse cluster.
Analytics copy fed from PostgreSQL while the application stays on PostgreSQL	Both, side by side	PostgreSQL keeps transactions while ClickHouse serves analytics, which avoids heavy scans on the primary.	When a second system adds more operating cost than the query speedup returns; confirm the replication path and restore tests first.
Regulated workload that needs tested backup and restore on a schedule	PostgreSQL or ClickHouse, decided by operations maturity	Both have documented backup approaches, but either needs regular restore tests on spare capacity to prove recovery.	Whichever platform your team can restore and verify on a schedule is the better choice for that environment.

How ClickHouse and PostgreSQL are built and what that means for operations

ClickHouse and PostgreSQL make different choices about how data is stored, replicated, failed over, authenticated and deployed. Those choices decide who gets paged, which tools you add, and how much of the operating work lands on your team. The cards below cover each area and what to check before you commit.

Column storage against row heap

ClickHouse stores each column separately, so a query that filters and aggregates a few columns across millions of rows reads far less data. The trade-off is that column storage makes single-row retrieval slower, per the ClickHouse documentation. PostgreSQL keeps whole rows together in a heap, which suits lookups by key and frequent row updates. Check which query shapes dominate your workload before you move reporting queries, and keep transactional writes in PostgreSQL unless you have measured the difference.

Replicated MergeTree with Keeper

ClickHouse replicates data through ReplicatedMergeTree tables, with coordination handled by ClickHouse Keeper. The replication guide recommends at least three Keeper nodes on dedicated hosts in production, so the coordination layer is a separate set of servers you must size, patch and monitor. A recovered replica syncs missing data from a healthy replica without manual steps, which reduces routine intervention. Confirm how many Keeper nodes your availability target needs before you size the cluster.

Hot standby and streaming replication

PostgreSQL replicates through hot standby servers that can serve read-only queries. You choose between synchronous replication, where a commit waits for standbys, and asynchronous replication, where it does not. Synchronous mode protects committed data at the cost of write latency, while asynchronous mode trades some possible data loss on failover for speed. Decide which mode matches your recovery point requirement before you build the topology, because changing it later means reconfiguring every standby.

Failover needs external tools

PostgreSQL does not detect a failed primary and notify a standby on its own. Automatic failover requires external software, which you select, configure, test and keep current. This is a real operating dependency: the tool chosen for promotion and client redirection becomes part of your incident path. ClickHouse replicas handle failover through Keeper coordination, so the question there is how you monitor the quorum. Ask your team to rehearse both failure paths before production.

Authentication options compared

PostgreSQL documents password, GSSAPI, SSPI, LDAP, RADIUS, certificate, PAM and OAuth client authentication, and PostgreSQL 18 added an OAuth 2.0 method. ClickHouse supports LDAP directories, Kerberos, SSL X.509 certificates, an HTTP authenticator and JWT authentication as external authenticators. Map your identity provider to each database before choosing, because the methods differ in which directories and token formats they accept. Confirm that your security team's required authentication path exists in the version you plan to run.

Deployment and upgrade cadence

ClickHouse ships stable releases roughly monthly and LTS releases twice a year, with each LTS supported for a year. PostgreSQL ships a major version about once a year and supports each for five years, with minor releases at least every three months. Minor PostgreSQL updates replace executables and restart, while major upgrades use dump and restore, pg_upgrade or logical replication. Plan a pre-production environment with representative data for either database, and read the ClickHouse changelog before each upgrade, since minor backward-incompatible changes can occur.

Feature comparison: ClickHouse against PostgreSQL

This table compares the two databases on license, release support, replication, backup, authentication, upgrades and failover, using only documented facts. Read each row as a question to answer for your own environment, and treat blank-looking gaps as items to confirm with the vendor and your own testing.

Capability	ClickHouse	PostgreSQL
License	Apache License 2.0 for the open-source server. ClickHouse Inc. separately sells ClickHouse Cloud.	PostgreSQL License, a permissive license similar to BSD or MIT, with no separate paid edition of the core database.
Release cadence and support	Stable releases roughly monthly; LTS releases twice a year, each supported for one year. Confirm the current supported list in the security policy before you pick a line.	One major version about yearly, each supported for five years. PostgreSQL 14 is supported until November 12, 2026; 18 runs until November 14, 2030.
Replication and coordination	ReplicatedMergeTree tables coordinated by ClickHouse Keeper, which replaces ZooKeeper. The guide recommends at least three Keeper nodes on dedicated hosts in production.	Streaming replication with hot standbys that serve read-only queries. Synchronous or asynchronous modes are both supported.
Backup and restore tooling	Built-in BACKUP and RESTORE for full and incremental backups to local disk, S3-compatible storage or Azure Blob Storage. Replication alone does not protect against human error.	Core documentation covers continuous archiving and point-in-time recovery. Confirm which backup tool your team will run and who tests restores.
Authentication methods	External authenticators include LDAP, Kerberos, SSL X.509 certificates, an HTTP authenticator and JWT. Confirm the setup for your identity provider.	Documented methods include password, GSSAPI, SSPI, LDAP, RADIUS, certificate, PAM and OAuth. SCRAM replaced MD5 as the preferred password method, and MD5 is deprecated in PostgreSQL 18.
Major-version upgrades	Upgrade paths depend on the release line and changelog. Minor-version backward-incompatible changes can occur, so test on representative data first.	Major upgrades use dump and restore, pg_upgrade, or logical replication, which works across major versions. PostgreSQL 18 pg_upgrade retains planner statistics.
High availability and failover	Replicas and Keeper provide the replication layer. Confirm the failover behavior and client routing you need in your own topology.	Hot standby and replication are built in, but the server does not detect primary failure. Automatic failover requires external tools that you must select, run and test.
Restore verification	The backup documentation advises regular restore tests on spare clusters, since untested backups often fail when needed.	Point-in-time recovery depends on archived WAL. Confirm that archiving and restore drills are part of the runbook from day one.

Licensing and editions for each platform and its managed options

The ClickHouse server is open source under the Apache License 2.0 (SPDX: Apache-2.0), according to its GitHub repository. Your team can run it on its own servers, in its own cloud accounts, or in an air-gapped network without a license fee to ClickHouse Inc. The license terms cover use, modification and redistribution, so the questions shift from purchasing to operating: who patches the server, who runs restore tests, and who supports upgrades.

No paid server edition: the supplied facts describe one open-source server under Apache-2.0 and do not describe a commercial self-hosted edition.
Apache-2.0 terms: the license permits internal use and modification, and includes a patent grant and a notice requirement for redistribution. Your legal team should confirm how these terms apply if you ship ClickHouse inside a product.
Support is yours to arrange: running the server yourself means your team or a partner such as DeployOpen covers installation, upgrades, backups and monitoring under your own contracts.
Version support is published: the security policy lists the currently supported versions, and anything outside that list is unsupported.
Trademarks are separate: the Apache-2.0 license does not grant rights to the ClickHouse name or logo, so confirm the trademark terms if you use the name in product branding.

Before deployment, ask your counsel to confirm in writing that Apache-2.0 obligations match your intended use, including any redistribution in customer-facing software.

How release and support cycles differ and what they ask of your team

ClickHouse and PostgreSQL move on very different clocks, and that difference sets the upgrade workload for your team. ClickHouse publishes stable releases roughly monthly and LTS releases twice a year, with each LTS line supported for one year after release, according to the ClickHouse production FAQ. The security policy currently lists 26.9, 26.8, 26.7 and 26.3 as supported with security updates, and every other version as unsupported. Because the supported set is short and moves quickly, a ClickHouse server that falls two or three stable releases behind can drop out of security coverage. Plan for a recurring upgrade cycle measured in months, not years, and confirm which line (stable or LTS) your environment will track before you build the runbook.

PostgreSQL asks for less frequent but longer-lived change. A new major version arrives about once a year, minor releases come at least once every three months, and each major version is supported for five years. The versioning policy lists 14 (to November 12, 2026), 15 (to November 11, 2027), 16 (to November 9, 2028), 17 (to November 8, 2029) and 18 (to November 14, 2030) as supported. Your PostgreSQL team therefore has a longer window to choose a major upgrade path, whether that is pg_upgrade, dump and restore, or logical replication, but must not let a major version run past its end date. Confirm the end-of-life date for whatever major version your analytics workloads depend on today.

Both cycles change what your team does in a staging environment. For ClickHouse, the production FAQ recommends a pre-production environment with representative data and queries, and reading the changelog before every upgrade because minor backward-incompatible changes can occur. Build that staging cluster early, keep it close enough to production to catch query regressions, and test restores on it as well, since the backup documentation advises regular restore tests on spare clusters. For PostgreSQL, minor updates do not change the storage format, so they are usually a restart-level task, while major upgrades need a rehearsed plan and a changelog review of the release notes. Ask your vendor or internal platform owner who signs off each change, who watches the security advisories for your chosen line, and how much calendar time each upgrade is budgeted to take.

What drives the running cost of each database

Running ClickHouse and PostgreSQL both cost more than the licence line, which is zero for each. The real spend sits in servers, coordination nodes, backup storage, the people who patch and restore them, and the support contract you buy or build yourself. The cards below separate who gets paid for each piece, what is one-time and what recurs, and what to put in a written quote.

Servers and coordination nodes

A replicated ClickHouse cluster needs ClickHouse Keeper for coordination, and the replication guide recommends at least three Keeper nodes on dedicated hosts in production, with about 4 GB of RAM each. Those hosts recur as cloud or hardware cost whether or not they serve queries. PostgreSQL high availability needs standbys and, for automatic failover, external tooling. Ask the quote to list every host by role, its memory and disk, and whether Keeper runs on dedicated machines or shares them with data nodes.

Backup storage and restore capacity

ClickHouse BACKUP and RESTORE write full or incremental backups to local disk, S3-compatible storage or Azure Blob Storage, and the documentation notes that replication does not protect against human error or corruption. Backup storage is a recurring cost that grows with retention. Ask the quote whether backups go to object storage, how many restore points are kept, and whether a spare cluster is priced for regular restore tests.

Upgrade and restore testing effort

ClickHouse stable releases ship roughly monthly and LTS releases twice a year, and the production guidance calls for a pre-production environment with representative data and queries plus a changelog review before each upgrade. PostgreSQL minor releases are simpler, but major upgrades need a planned path through pg_upgrade or logical replication. The recurring labour is testing, not the upgrade itself. Ask who runs the staging environment, how many upgrade cycles a year the quote covers, and whether restore tests are included.

Skills and internal staffing

Running ClickHouse well means knowing ReplicatedMergeTree, Keeper quorum behavior, table design for column storage and external authenticators such as LDAP, Kerberos or JWT. Running PostgreSQL means knowing replication modes, failover tooling, connection pooling and authentication methods such as SCRAM, GSSAPI or certificates. Staffing is the largest recurring cost for most teams. Ask who on the team owns each database, how that role is covered during on-call, and what knowledge transfer the quote includes.

Support contracts and who sells them

Open-source ClickHouse and PostgreSQL carry no vendor support fee, but production teams often buy it from a commercial provider, a managed service or an implementation partner. ClickHouse Inc. sells ClickHouse Cloud, and self-hosted support comes from other vendors or your own team. DeployOpen implements, hardens, backs up, upgrades and supports self-hosted platforms under written scope and retainers. Ask each provider which versions it covers, its response terms and whether it will sign off a restore test.

Licence and managed service fees

ClickHouse server is Apache-2.0 and PostgreSQL uses the PostgreSQL License, so neither charges a licence fee for self-hosting. The cost question is whether a managed service is cheaper than your own operating effort. ClickHouse Cloud is metered separately for compute and storage by tier, and managed PostgreSQL services price differently again. Ask every managed quote for compute, storage, backup and egress as separate lines, plus the one-time migration cost.

Moving analytics from PostgreSQL to ClickHouse step by step

This sequence moves reporting and analytical queries off PostgreSQL in controlled stages, so each step ends with evidence that ClickHouse returns the same answers, restores from backup and can take over the reporting load.

Confirm the query workload and data
Your analytics team and the owners of the PostgreSQL reporting schema list the queries that scan many rows, the ones that run against single rows, and the freshness each report needs. Pick a representative slice of tables and history, then record row counts, date ranges and the reports that depend on them. This step is done when the team has a written inventory of queries to move, the ones that stay in PostgreSQL, and the data volumes each one touches. If most of the pain comes from single-row lookups or frequent updates, stop here and reconsider the fit.
Stand up a pre-production ClickHouse environment
Your platform team installs a ClickHouse server in a non-production environment inside your own infrastructure, using a stable release line rather than an LTS line unless your policy requires otherwise. The ClickHouse production guidance recommends a pre-production environment with representative data and queries, so load a copy of the slice from step one. Confirm the version you run is in the supported list on the ClickHouse security policy. This step is done when the representative data loads and the server answers test queries.
Redesign schemas and choose an ingestion path
Analytics schemas rarely match transactional ones. Your data engineers redesign tables around ClickHouse MergeTree engines, sort keys and partitioning that fit the filters your reports use, and they choose how data arrives: a scheduled batch export from PostgreSQL, change data capture into a stream, or a periodic load. If you need replicated tables, the replication path uses ReplicatedMergeTree coordinated by ClickHouse Keeper, which needs its own nodes and a backup plan. This step is done when a written design covers each table, its engine, its keys and the chosen load method, and the replication decision is recorded.
Validate results against PostgreSQL
Run the same reports against PostgreSQL and ClickHouse over the same data window, then compare row counts, sums, distinct counts and the figures finance or operations rely on. Investigate every mismatch, which often comes from time zones, null handling, rounding or late-arriving rows. Query logic transfers in most cases, but functions and date handling often need rewriting. This step is done when every report in scope matches within rules the business has signed off and the mismatches are documented.
Build access rules and pipelines
Access control and pipelines are rebuilt rather than copied. Your security team maps PostgreSQL roles and row-level restrictions onto ClickHouse users, roles and grants, and checks the external authenticators you plan to use, such as LDAP or JWT, against your identity standards. Your data engineers rebuild the scheduled loads, retries and monitoring. This step is done when a reviewer confirms each reporting group sees only the rows it should, and the pipelines run without manual intervention for a agreed test period.
Run backup and restore tests
ClickHouse replication does not protect against human error or corruption, so your operations team configures BACKUP and RESTORE to a location you control, such as local disk, S3-compatible storage or Azure Blob Storage, and runs a full restore onto a spare cluster. The ClickHouse backup documentation warns that a backup never test-restored will probably not restore properly, so repeat the restore test on a schedule. This step is done when a restored copy passes the same validation checks from the previous step.
Cut over reporting
Move dashboards and scheduled reports to ClickHouse in groups, starting with the lowest-risk ones, and keep the PostgreSQL version available for a fallback window your business agrees on in advance. Monitor query latency, load failures and data freshness against the targets set in step one. This step is done when every in-scope report reads from ClickHouse, the fallback path has been exercised, and the business owners accept the output.
Retire duplicated paths
Once cutover is accepted, remove the duplicate PostgreSQL reporting queries, the old jobs and the unused grants, and update runbooks, documentation and the upgrade plan for both systems. Transactional workloads remain in PostgreSQL. Moving those is a different and larger project that touches application writes, consistency and failover, so treat it as a separate scope. This step is done when the old paths are removed, the runbooks name owners for both databases, and the decommission record is signed off.

What implementing each involves and where projects usually run long

Standing up a ClickHouse cluster is mostly a coordination and recovery exercise. A replicated layout uses ReplicatedMergeTree tables coordinated by a ClickHouse Keeper quorum, and the replication guide recommends at least three Keeper nodes on dedicated hosts in production, with about 4 GB of RAM each. Budget for that host count, the replica placement and the network paths between them before the first table is created. The part teams most often leave for later is backup design. Replication protects against hardware loss but, as the backup documentation notes, not against human error or corruption, so plan full and incremental BACKUP and RESTORE jobs to local disk, S3-compatible storage or Azure Blob Storage, and schedule restore tests on spare clusters. The documentation warns that a backup never test-restored will probably not restore when needed, so ask the implementer to include restore drills as a written deliverable rather than an afterthought. Confirm access model early too: ClickHouse supports LDAP, Kerberos, X.509 certificates, an HTTP authenticator and JWT as external authenticators, and wiring those to your directory is a separate workstream.

Extending an existing PostgreSQL estate is usually smaller in scope but touches more running systems. Connection pooling with PgBouncer is often the first change, because it alters how every application authenticates and how transactions are pooled, so test each client driver against it. Replication and failover come next. PostgreSQL supports hot standbys that serve read-only queries and both synchronous and asynchronous replication, but it does not detect a primary failure or notify the standby, so automatic failover depends on external tooling you must select, configure and test. Major upgrades add another planning point: logical replication works across major versions and can keep downtime to several seconds, while pg_upgrade is the alternative. Confirm which PostgreSQL major version you will run against the support dates in the versioning policy, since version 14 is listed to November 12, 2026.

Projects run long in four places. Data modeling for analytics is the largest: wide, denormalized tables, sort keys and partitioning choices made for PostgreSQL rarely suit column storage, and rework after load testing is expensive. Pipeline reliability is next, because batch loads, retries and late-arriving data must be made idempotent before anyone trusts the numbers. Access control integration stalls when the directory mapping, role design and audit requirements are discovered late. Untested backups complete the list, since a restore failure found during an audit or incident extends the schedule by much more than the drill would have cost. DeployOpen plans, implements and documents these workstreams under a fixed scope agreed in writing before work starts, and that written scope should name each component, each restore test, each authenticator and each handover item. Ask any implementer, DeployOpen included, to state the deliverables, the acceptance tests and the parts the client must provide, and to price each one separately so you can see what recurs after go-live.

Questions buyers ask before choosing or hiring help

Can PostgreSQL be tuned enough instead of adding ClickHouse?

Often it can for a while, and that is the first thing to test. PostgreSQL supports hot standby servers that serve read-only queries, and it has improved in recent majors, including asynchronous I/O in PostgreSQL 18. Tuning, indexing, partitioning and summary tables can carry many analytical workloads. The signal to move is different: when wide scans and aggregations over large history dominate your load, and tuning only buys time. Ask for a written test plan that runs your own queries and data volumes against both databases before any scope is agreed.

What does the work need from our internal team?

The team needs people who own the database, the query workload and the data pipelines. Column storage is fast for filtering and aggregation but slower for single-row retrieval, so application teams must change query patterns, not just connection strings. Replication for ClickHouse is coordinated by ClickHouse Keeper, which the replication guide recommends running as at least three nodes on dedicated hosts in production. Backups need owners too: the backup documentation warns that a backup never test-restored will probably not restore properly. Ask the engagement to name which of these tasks stay with your staff after handover.

How long does a migration take, and what drives that time?

No fixed duration can be given here without your workload, so treat any single number with suspicion. The main drivers are the number of tables and queries that move, how much history must be backfilled, how many downstream dashboards and applications read PostgreSQL directly, and whether both databases must run side by side during cutover. For PostgreSQL itself, the upgrading documentation notes that logical replication works between major versions. Ask for a written scope that lists each workload, the cutover approach and the test steps, so the timeline follows from agreed deliverables.

Can we run ClickHouse ourselves without outside help?

Some teams can, provided they have database operators who understand replicas, Keeper quorums, upgrades and backup restores. The ClickHouse production FAQ recommends stable releases for most production use, a pre-production environment with representative data and reading the changelog before each upgrade, since minor backward-incompatible changes can occur. Confirm current support windows on the ClickHouse security policy before you pick a line: it lists 26.9, 26.8, 26.7 and 26.3 as supported with security updates. Outside help is most useful for the first deployment, the upgrade process, and restore testing, which can be bought as a fixed-scope engagement or as a retainer for ongoing support.

What changes if we compare ClickHouse Cloud instead of self-hosting?

The question shifts from who runs the servers to who controls the data path and the operating model. ClickHouse Inc. sells ClickHouse Cloud as a managed service, while the open-source server is Apache-2.0 licensed and runs in your own infrastructure. Cloud changes the cost structure, because compute and storage are metered by tier rather than paid as hardware and staff time, and it changes which engines, authentication methods and system settings you can use. Those differences belong in a separate comparison. Ask for written answers on data residency, backup ownership and exit terms before you decide.

What does a fixed-scope engagement cover for this comparison?

DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For this decision, a typical written scope might cover a workload assessment, a test of your own queries against both databases, a ClickHouse deployment with replication and backups, restore tests, and handover documentation. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing upgrades and continuous support are available as retainers. DeployOpen does not publish a price list, so a quote follows from the written scope.

How do PostgreSQL and ClickHouse fit together in our data stack?

Many teams keep PostgreSQL as the system of record for transactions and run ClickHouse beside it for analytics, copying data across with a pipeline. Ask who owns that pipeline, how late data is handled and how the two stores are reconciled. PostgreSQL offers hot standby replicas, synchronous and asynchronous replication, and the PostgreSQL failover documentation notes that automatic failover needs external tools. ClickHouse uses ReplicatedMergeTree tables, and a recovered replica syncs missing data from a healthy replica without manual steps. Replication still does not protect against human error, so both databases need separate backup plans.

How DeployOpen helps choose, implement or migrate

DeployOpen plans, implements and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, so the ClickHouse vs PostgreSQL decision is tested against your real workload and environment. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we scope

Written scope lists which analytical queries, data volumes and users would move or stay in PostgreSQL.
We define the test workload, representative data and the query shapes that must be measured.
Scope names the authentication, replication, backup and upgrade decisions the team must own.
Deliverables, timelines and responsibilities are agreed in writing before any work begins.

How we build

We stand up a pre-production ClickHouse environment with representative data and queries for comparison.
Replicated layouts are built with ReplicatedMergeTree tables and ClickHouse Keeper nodes on dedicated hosts.
Authentication is configured against your directory using LDAP, Kerberos, certificates or JWT as your policy requires.
We test BACKUP and RESTORE runs and document the restore procedure before any production cutover.

How we hand over

Handover documents the chosen version line, the upgrade path and the changelog review step for each release.
Runbooks cover replica recovery, backup schedules, restore tests on a spare cluster and monitoring.
We document how analytics feeds stay running side by side with PostgreSQL during and after any migration.
Your team receives configuration, evidence and operating notes that your own staff can maintain.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainers can cover planned moves between ClickHouse stable and LTS release lines as support windows change.
Recurring restore tests and query performance checks can be scheduled against your agreed scope.
Ask any provider to confirm which items sit inside the fixed scope and which sit in a retainer.

ClickHouse vs PostgreSQL