Choose ClickHouse or TimescaleDB for time-series and event data?
If your time-series or event data already lives in PostgreSQL and your queries are mostly time-bounded scans, rollups and dashboards over that data, TimescaleDB keeps the work inside one database. It is a PostgreSQL extension, so the same roles, backups, client drivers and SQL skills your team uses today still apply. If your workload is dominated by wide aggregations over very large event volumes, or by many concurrent analytical users, a separate ClickHouse column store is built for that shape of query. It adds a second system to run, but it is designed for scans over many rows rather than for sharing a relational database with transactional work.
The decision turns on five questions. First, query shape: how many rows does a typical analytical query touch, and how often do you fetch single records? Second, update frequency: how often do rows change after they are written? Third, your existing PostgreSQL investment, including the operational runbooks and extensions you already maintain. Fourth, licensing: TimescaleDB's Community Edition features fall under the Timescale License, which permits running it in your own infrastructure but not offering it as a service, while the Apache 2 Edition can be sold as a service, and ClickHouse server is Apache-2.0. If you plan to resell the platform, confirm which edition and terms apply before you design around them. Fifth, the team: who will patch, back up, restore-test and upgrade a second database, and how many people can cover it?
Which scenarios favor each database
This table maps common ClickHouse and TimescaleDB scenarios to the platform that usually fits better and the condition that decides it. Read each row against your own write rate, query shapes and existing PostgreSQL footprint, since the right answer often depends on whether the data must sit next to transactional tables.
| Scenario | Better fit | Condition that drives the choice |
|---|---|---|
| High-volume append-only event analytics | ClickHouse | Choose ClickHouse when ingest reaches a volume where you want a column store built for large scans and aggregations, and when most queries aggregate many rows rather than fetch single events. Confirm the sustained insert rate you need in a test with your own data. |
| Dashboards over long retention windows | ClickHouse (usually) | Column storage favors broad aggregations across months of data. TimescaleDB's columnstore (Community Edition) and retention policies also cover long windows, so run your dashboard queries against both before deciding. |
| Mixed transactional and time-series workloads | TimescaleDB | When time-series rows must join with customer, account or order tables in the same transaction, keeping them in PostgreSQL avoids cross-database synchronization. ClickHouse is weaker at single-row lookups and updates. |
| Teams already running PostgreSQL | TimescaleDB | If your team already operates PostgreSQL, uses its backup, replication and tooling, and the data fits a single cluster, adding the extension avoids a second database to patch, back up and monitor. Confirm that your PostgreSQL major version is supported and that the extension is available in your environment. |
| Teams without PostgreSQL skills but with ClickHouse operations skills | ClickHouse | If your platform team already runs ClickHouse with ReplicatedMergeTree and Keeper, a second database is less of a burden. Otherwise the operating model of a separate column store adds effort that a PostgreSQL shop may not want. |
| Offering the database as a hosted service to customers | Check license terms first | TimescaleDB Community Edition under the Timescale License cannot be offered as a service, while the Apache 2 Edition can. ClickHouse is Apache-2.0 licensed. Have counsel confirm the terms for your model before choosing either. |
| Strict upgrade and support windows | Confirm with each vendor | ClickHouse publishes stable releases roughly monthly and LTS releases twice a year, with LTS supported for a year. PostgreSQL 18 is supported until November 14, 2030. Map your own upgrade cadence against both schedules. |
| Writes that need frequent in-place updates | TimescaleDB | PostgreSQL handles row-level updates and deletes with standard transactional behavior. ClickHouse favors append-heavy patterns, so frequent corrections to historical rows need a design review before you commit. |
How ClickHouse and TimescaleDB are built and deployed
ClickHouse runs as its own column-oriented server and replicates through ClickHouse Keeper, while TimescaleDB adds hypertables to a PostgreSQL instance you may already operate. The cards below cover what each design means for replication, failover, backup and the number of systems your team must run.
Separate server with its own storage
ClickHouse is a standalone column-oriented SQL server with its own data format, query engine and storage layout. TimescaleDB is an extension loaded into PostgreSQL, so its data lives in the same database cluster as your relational tables. A separate ClickHouse server means a second engine to patch, monitor, size and secure, along with new connection paths from applications. Check whether your team already runs PostgreSQL operations that could absorb the extension, and whether a second engine is justified by the query workload.
Keeper quorum for replicated tables
ClickHouse replicates ReplicatedMergeTree tables through ClickHouse Keeper, which replaces ZooKeeper. The replication guide recommends at least three Keeper nodes on dedicated hosts in production, with about 4 GB of RAM each. Those nodes are extra machines to provision, patch and monitor even when the data nodes are small. A recovered replica syncs missing data from a healthy peer on its own, which reduces manual recovery work once the quorum is in place.
Hypertables inside PostgreSQL
TimescaleDB partitions time-series tables into hypertables that PostgreSQL manages as regular tables, so existing roles, schemas, extensions and client drivers keep working. Your team writes SQL against the same database that serves transactional data. The trade-off is that the performance of the time-series workload now shares the instance's memory, storage and vacuum behavior with the rest of the application. Confirm which TimescaleDB features your edition provides before designing around them, since continuous aggregates and the columnstore sit in the Community Edition only.
PostgreSQL failover needs external tools
PostgreSQL supports hot standbys that serve read-only queries, plus synchronous and asynchronous replication. It does not detect a failed primary or promote a standby by itself, so automatic failover depends on tools you select and operate. TimescaleDB inherits this model because it runs inside PostgreSQL. ClickHouse's replicas handle failure through the Keeper quorum instead. Ask your team who owns the failover tooling, how it is tested, and what recovery time your service must meet before you choose the database.
Backup and restore testing
ClickHouse BACKUP and RESTORE cover full and incremental backups of tables, partitions or databases to local disk, S3-compatible storage or Azure Blob Storage. The documentation notes that replication does not protect against human error or corruption. Backups for TimescaleDB follow PostgreSQL practice, such as continuous archiving and point-in-time recovery. In both cases, a backup that has never been test-restored will probably fail when you need it, so schedule restore tests on a spare cluster as part of the operating budget.
Footprint of a second database
Running ClickHouse next to PostgreSQL adds a separate install, configuration, upgrade path, monitoring target, credential store and backup job. Each engine has its own release cadence and support window that your change calendar must follow. Keeping time-series data in PostgreSQL keeps one engine, one backup estate and one set of access controls, which is often the lower operating load at moderate volumes. Ask your team to list every system that would need an on-call runbook before deciding the second database is worth it.
How writes, updates and query speed at scale differ
ClickHouse stores data by column, which speeds filtering and aggregation over many rows but makes retrieving a single row slower, according to the ClickHouse introduction. That trade-off is the core of this comparison. A dashboard that scans billions of events to compute counts per device per hour fits the column model well. A workload that fetches one device's latest reading by key, or updates individual rows frequently, fits a row-oriented store better. TimescaleDB runs inside PostgreSQL, so it keeps PostgreSQL semantics for inserts, updates, constraints, joins and transactions on the same tables your applications already use. Its columnstore (Hypercore) and continuous aggregates are features of TimescaleDB Community Edition, not the Apache 2 Edition, and they are where its analytical speedups apply.
Continuous aggregates and the columnstore change how TimescaleDB handles time-series scans, but they do not turn PostgreSQL into a column store. Hypertables partition data by time, and the columnstore compresses older chunks for analytical reads. Teams should check which of their queries touch recent, uncompressed data, which touch historical chunks, and how often rows are updated after they are written. Late-arriving or frequently corrected events behave differently in each system, and that difference often decides the result more than average query time does. Confirm the update pattern and the retention policy with the vendor documentation before you size either system.
No performance figures for either database are supplied here, so this page does not claim which one is faster for your data. Build a test that replays a representative slice of your ingest rate, update pattern, query mix and retention window against both candidates on hardware that matches your target environment. Record ingest throughput, p95 query latency for the top dashboard and API queries, storage size and the time to restore a backup. Run the same test on the PostgreSQL version you already operate, because the answer can change with your indexing and compression choices.
Capability comparison: ClickHouse against TimescaleDB
This table compares the two platforms on license, SQL and tooling, updates, replication, backup, authentication, managed options and high availability. Read each row as a question to answer for your own workload, and treat cells marked for confirmation as items to verify before you commit.
| Capability | ClickHouse | TimescaleDB |
|---|---|---|
| License | Server is Apache-2.0 licensed, per its GitHub repository. ClickHouse Inc. sells ClickHouse Cloud separately. | Split license: code outside the tsl directory is Apache-2.0, while Community Edition features fall under the Timescale License, which does not allow offering it as a service. |
| SQL and tooling | Column-oriented SQL database built for analytical queries over many rows. Confirm the SQL dialect and client drivers your applications need. | PostgreSQL extension, so existing PostgreSQL SQL, clients and tooling carry over. Continuous aggregates, columnstore and retention policies require Community Edition or Tiger Cloud. |
| Updates and single-row changes | Column storage makes single-row retrieval and point updates slower than in row stores. Test your update pattern before choosing it for mutable records. | Inherits PostgreSQL row-level behavior for updates, with columnstore features layered on for time-series data. Confirm how your update rate interacts with the columnstore. |
| Replication | ReplicatedMergeTree tables coordinated by ClickHouse Keeper. A recovered replica syncs missing data automatically from a healthy replica. | Uses PostgreSQL replication: hot standbys serving read-only queries, plus synchronous or asynchronous modes. Confirm the replication mode your durability target requires. |
| Backup and restore | BACKUP and RESTORE cover full and incremental backups to local disk, S3-compatible storage or Azure Blob Storage. Replication alone does not protect against human error. | Backup relies on PostgreSQL tooling such as continuous archiving and point-in-time recovery. Confirm the tooling and restore testing your team will own. |
| Authentication | External authenticators include LDAP, Kerberos, SSL X.509 certificates, an HTTP authenticator and JWT authentication. Confirm which matches your identity provider. | Inherits PostgreSQL client authentication methods, including password, GSSAPI, SSPI, LDAP, RADIUS, certificate, PAM and OAuth. Confirm the method your environment supports. |
| Managed options | ClickHouse Cloud is sold by ClickHouse Inc. Confirm its regions and data residency options against your requirements. | Tiger Cloud plans are listed on the Tiger Data pricing page, with Enterprise pricing set by quote. Confirm plan limits and support terms before you rely on them. |
| High availability | Failover depends on replica count and Keeper quorum. Confirm the node layout and monitoring your availability target needs. | PostgreSQL does not detect primary failure on its own, so automatic failover requires external tools. Confirm which tool your team will operate. |
What the licenses allow and what each edition includes
The ClickHouse server is open source under the Apache License 2.0, so your team can install, modify and run it in its own infrastructure without a license fee. ClickHouse Inc. separately sells ClickHouse Cloud as a managed service, which is a different product with its own metering. The open-source license covers the server code. It does not cover a managed offering that ClickHouse Inc. operates for you, and the two should be evaluated on their own terms.
- Server license: The ClickHouse repository is licensed under Apache-2.0, which permits commercial internal use, modification and redistribution under its terms.
- Managed service: ClickHouse Cloud is sold by ClickHouse Inc. as a managed service, with pricing and terms set by that vendor.
- No edition split: The open-source server is not divided into paid feature tiers in the material reviewed here, so confirm this with ClickHouse before assuming it.
- Support windows: Supported versions are listed in the project's security policy, so the license alone does not guarantee security updates for a given release.
- Vendor agreements: Any commercial support contract is a separate purchase from the license and should be scoped in writing.
Before you commit, confirm with your legal team whether your use of the Apache-2.0 server, your internal hosting and any third-party redistribution fit your obligations, and ask ClickHouse for the current terms of any managed or support agreement.
TimescaleDB ships under two editions with different licenses, and the feature set depends on which one you install. The Apache 2 Edition is licensed under Apache-2.0 and can be sold as a service. The Community Edition is licensed under the Timescale License and includes features such as continuous aggregates, the columnstore (Hypercore) and data retention policies. Both editions are built from the same repository, but the code inside the tsl directory and the shared object files with -tsl in their names fall under the Timescale License.
- Apache 2 Edition: Covers the code outside the
tsldirectory and can be offered as a hosted service. - Community Edition features: Continuous aggregates, the columnstore, data retention policies, job scheduling and functions such as
time_bucket_gapfillare available only in the Community Edition. - Self-run use: You can install the Community Edition on your own on-premises or cloud infrastructure and run it for free under the Timescale License.
- Service restriction: The Timescale License does not allow you to offer the Community Edition as a service to others.
- Build check: Confirm which shared object files your package installs, because the file names show which license applies.
Before you plan around a feature, check the editions page and the LICENSE file for the release you intend to run, and confirm with your legal team whether your use counts as offering a service.
The most common licensing mistake with TimescaleDB is treating the Community Edition as open source for any use. Under the Timescale License, you can run it for your own purposes on infrastructure you control, but you cannot offer it as a service. A product that gives customers access to a TimescaleDB-backed database, or a hosted analytics platform sold to third parties, may fall outside what the license allows, depending on how it is built and sold.
- Permitted: Running the Community Edition for your own applications and internal analytics on your own servers or cloud accounts.
- Restricted: Offering the Community Edition as a managed or hosted service to other organizations.
- Managed alternative: Tiger Cloud is Tiger Data's hosted offering, and its plans and terms are set by that vendor.
- Apache 2 alternative: If you need to offer a service and do not need the Community features, the Apache 2 Edition is the option the license permits for that purpose.
- Shifting terms: Licenses and editions can change between releases, so re-check the license on each upgrade.
Before you design a customer-facing product on TimescaleDB, ask your legal team to review the Timescale License against your exact delivery model.
TimescaleDB runs as an extension inside PostgreSQL, so the PostgreSQL License sits underneath both editions. PostgreSQL is released under a liberal open-source license similar to the BSD or MIT licenses. That license is permissive and does not restrict hosting PostgreSQL as a service, but the extension you add on top may carry different terms. Your licensing review should cover both layers in the same pass.
- Core engine: PostgreSQL is under the PostgreSQL License, which allows commercial use, modification and redistribution.
- Extension layer: TimescaleDB adds its own license terms on top, so the full stack is governed by two sets of terms.
- Version support: PostgreSQL major versions are supported for five years, so the base database has its own lifecycle separate from the extension.
- Managed providers: Cloud providers that host PostgreSQL may offer their own managed products with their own terms, which are separate from both licenses.
- Dependency review: Other extensions in your database may bring additional licenses that also need review.
Before you sign off on a stack, list every extension and its license, and confirm the PostgreSQL major version against the support dates in the PostgreSQL versioning policy.
What drives the running cost of each platform
Both platforms are free to download, so the running cost comes from the people, infrastructure, support and upgrade work around them. The cards below separate the recurring costs from the one-time ones and name the figures a quote should include.
Infrastructure and storage footprint
Both stacks bill you for the servers, disks and backup storage you run, and that cost scales with data volume and retention. TimescaleDB adds compression and retention policies inside PostgreSQL, so one database may serve both transactional and time-series tables. ClickHouse usually needs a separate server or cluster, plus Keeper nodes once you replicate. Ask the quote to price each layout, including replicas, backups and any object storage.
Staff skills for each stack
A team that already runs PostgreSQL can operate TimescaleDB with existing tools, backup routines and on-call knowledge. Running ClickHouse adds a second database engine, its replication model, Keeper and its backup and restore procedures. The main recurring cost is the engineer hours to keep both skill sets current. Ask the quote to state which roles are needed and which are already covered by your staff.
Tiger Cloud plan pricing
If you choose the managed service, Tiger Cloud publishes Performance plans from $30 per month and Scale plans from $36 per month, with Enterprise priced on request. A free 30-day trial of the Performance plan is available. These are recurring fees that rise with the plan tier, so check which features, storage and compute each plan includes before comparing them with self-hosted costs.
Enterprise support terms
Tiger Cloud includes developer support by email on all plans. 24x7 production support is a paid add-on, and the Enterprise plan includes it with a 1-hour response time for Sev 1 issues. Confirm whether that response time covers your region and severity definitions in writing. Self-hosted TimescaleDB Community Edition has no vendor support contract unless you buy one, so budget for a support provider or your own on-call rota.
ClickHouse support depends on the provider
ClickHouse is Apache-2.0 licensed and free to run, but support cost depends on who operates it. ClickHouse Inc. sells ClickHouse Cloud, and other providers offer their own contracts. A self-hosted team must decide between internal staff and a partner for production incidents. Ask any provider which versions it supports, its response times and whether it covers backup restore testing, because ClickHouse's security policy supports only some release lines at a time.
Edition choice and licensing
TimescaleDB features such as continuous aggregates, the columnstore, data retention policies and job scheduling are available only in Community Edition, which is licensed under the Timescale License. You may run it free in your own infrastructure but cannot offer it as a service. Choosing the Apache 2 Edition changes which features you get. Ask the quote to state the edition, and confirm your use case fits the license before committing.
Upgrades and restore testing
Upgrades recur for both platforms. PostgreSQL minor releases replace executables and need a restart, while major upgrades use dump and restore, pg_upgrade or logical replication. ClickHouse suggests a pre-production environment with representative data and a changelog review before each upgrade. Restore testing also recurs, because a backup never restored is unlikely to work. Ask the quote for the upgrade cadence, the test environment and who runs restore drills.
Moving data between ClickHouse and TimescaleDB
This sequence shows how a team moves time-series and event workloads from one engine to the other without a blind cutover. It ends with both systems validated against the same queries and a restore-tested backup in place.
Inventory query shapes and retention rules
The data owner and the engineers who run the dashboards list every query that matters, grouped by shape: point lookups by device or user, time-window aggregations, joins to reference tables and ad hoc exploration. For each shape they record the latency and freshness the business expects, plus current retention and deletion rules. Done means a signed-off list that maps each query to an owner and each dataset to a retention policy. Ask both vendors and your own team which features each query depends on, because continuous aggregates and retention policies exist only in TimescaleDB Community Edition, so any reliance on them changes the target design.
Export data with checked row counts
The engineering team exports history in time-bounded batches from PostgreSQL or from the ClickHouse table, writing to Parquet, CSV or a staging database that both sides can read. Each batch is recorded with its row count, time range and a checksum, and the same figures are computed on the source. Done means every batch reconciles to the source and the export log is stored with the migration record. Confirm that updates and deletes made during the export window are captured, since a copy taken before a late change can silently diverge from production.
Rebuild schemas, indexes and jobs
Table designs are redone for the target engine rather than copied. In TimescaleDB that means hypertables, chunk intervals and any compression or columnstore settings chosen for the workload. In ClickHouse it means MergeTree-family table definitions, sorting keys, partitioning and, for replicated layouts, ReplicatedMergeTree tables. Retention, aggregation and scheduled jobs are rewritten for the new platform and tested in isolation. Done means the schema review is approved and a test load completes. Expect this to be the largest rebuild item, because the data model is not portable and the design choices differ between a row-oriented extension and a column store.
Rewrite SQL and time functions
Engineers translate application queries and the functions they depend on, such as time bucketing, gap filling, window logic and JSON handling. Each rewritten query is tagged with the source query it replaces. SQL knowledge carries over, but function names, null handling and some join behavior do not, so every change is reviewed rather than auto-translated. Done means each query in the inventory has a reviewed target version and any function with no direct equivalent is recorded as an application change with an owner.
Rebuild dashboards and point consumers
BI and dashboard definitions are recreated against the new data source, with their filters, refresh intervals and access rules checked. Application and service connections are updated in a staging environment first. Done means each dashboard shows the same figures as the old one for an agreed sample period, and the consumer list confirms that no unknown client still reads the old database.
Run both systems in parallel and validate results
Both databases receive the same incoming data for an agreed period while consumers keep reading from the current system. The team compares query results, latency and resource use for every query in the inventory and investigates each mismatch. Done means every difference is explained and accepted by the data owner, and the results are kept as evidence. Confirm the validation covers late-arriving and updated records, since those are where engines most often disagree.
Pass backup restore tests as a cutover gate
Before cutover, the team restores a backup of the new system to a spare environment and checks row counts and sample queries against the source. ClickHouse documentation warns that a backup never test-restored will probably not restore properly, and replication alone does not protect against human error, so the test covers both the backup and a restore of the new layout. The same restore test is repeated on the PostgreSQL side if it remains a source of record. Done means restores succeed, the results match and the runbook records the procedure and the owner.
Cut over and keep a rollback path
The team switches writes and reads to the new system during an agreed window, with the old system kept read-only for a period that the owner sets. Rollback steps are written and rehearsed before the switch. Done means the consumer list shows no traffic to the old endpoint, monitoring confirms freshness and error rates, and the decommissioning date is approved in writing. Confirm with your vendor and your own environment what support covers the cutover window, because support terms vary by plan and provider.
Where implementation projects usually run long
Implementation projects on the ClickHouse side usually run long in the replication and recovery work, not in the first schema. A replicated layout uses ReplicatedMergeTree tables coordinated by ClickHouse Keeper, and the replication guide recommends at least three Keeper nodes on dedicated hosts in production, with about 4 GB of RAM each. Teams that plan for one server and later add a quorum often slip on host provisioning, network placement and Keeper ports. Ask your platform team to confirm who provisions the three Keeper hosts, who owns their patching, and whether your change process allows a rolling restart of replicas. Backup is the other long tail. The backup documentation says replication does not protect against human error or corruption, and that a backup never test-restored will probably not restore when needed. Budget for scheduled restore tests on a spare cluster, and confirm where backups land: local disk, S3-compatible storage or Azure Blob Storage.
Upgrade planning also takes longer than teams expect. ClickHouse publishes stable releases roughly monthly and LTS releases twice a year, with LTS releases supported for a year. The security policy lists 26.9, 26.8, 26.7 and 26.3 as currently supported, so choosing a line determines how often you must upgrade. The production FAQ recommends a pre-production environment with representative data and queries, and reading the changelog because minor backward-incompatible changes can occur. Client must supply that staging environment and a representative query set before go-live.
On the TimescaleDB side, the extension itself is quick to add, but the surrounding PostgreSQL work is where projects slip. Confirm the PostgreSQL major version against the versioning policy before you commit, because version 14 is supported only to November 12, 2026. Major upgrades use pg_dumpall and restore, pg_upgrade, or logical replication, and the upgrade path for a hypertable-heavy database needs its own rehearsal. Failover is another gap: PostgreSQL does not detect a primary failure on its own, so you must select and operate external failover tooling, and the client must supply the on-call ownership for that tool. Also confirm whether the Community Edition features your design needs, such as continuous aggregates and the columnstore, are licensed for your deployment model under the Timescale License.
Questions buyers ask before choosing between ClickHouse and TimescaleDB
Can PostgreSQL handle our event volume without a second database?
Often yes, and that is the first thing to test. TimescaleDB runs inside PostgreSQL and adds hypertables, the columnstore (Hypercore), continuous aggregates and retention policies, but those features are only in the Community Edition under the Timescale License, not the Apache 2 Edition. The deciding factors are your sustained ingest rate, how many rows your dashboards scan per query, how many concurrent analytical users you expect, and whether your team already runs PostgreSQL well. Keeping data in one engine avoids a second backup, upgrade and security surface. Load a representative week of your own events into both systems and measure the queries your users actually run before choosing.
What does migrating event data from PostgreSQL to ClickHouse involve?
The effort comes from schema translation, query rewrites and the write path, not from copying rows. ClickHouse uses its own MergeTree table engines and a different approach to updates, so existing UPDATE-heavy logic, triggers and PostgreSQL-specific functions need review. Cost drivers include the number of event tables, the number of dashboards and API queries that read them, how ingestion is wired today, and how much history must move. Ask any implementation partner for a written scope that lists each table, query group, ingestion path and cutover step, and a validation plan that compares results between the two systems. Fixed-scope work is agreed in writing before it starts.
Do we need a second database alongside PostgreSQL?
You need one only when PostgreSQL cannot meet a specific analytical requirement at acceptable cost. Keeping operational rows in PostgreSQL and sending a copy of event data to ClickHouse is a common split, but it adds a replication or ingestion pipeline, a second backup regime and a second set of access controls. PostgreSQL's own documentation covers hot standbys, synchronous and asynchronous replication, and external failover tooling, so the operational base is well understood. Justify the second system with measured query latency, data volume or concurrency, and write down who owns the pipeline between the two.
What does the license mean if we offer analytics as a hosted service to customers?
The license terms differ in a way that matters for hosted offerings. ClickHouse server is Apache License 2.0, so self-hosting it and offering it as part of a service is governed by that permissive license. TimescaleDB's Community Edition is under the Timescale License, which permits running it on your own on-premises or cloud infrastructure for free but prohibits offering it as a service. The Apache 2 Edition of TimescaleDB can be sold as a service but lacks continuous aggregates, the columnstore and retention policies. Have legal counsel review the exact license text and the edition you plan to ship before committing to an architecture.
How much work does a self-hosted ClickHouse cluster need to run?
A replicated ClickHouse cluster needs coordination, backups and upgrade planning that a single PostgreSQL instance does not. ReplicatedMergeTree tables are coordinated by ClickHouse Keeper, and the replication guide recommends at least three Keeper nodes on dedicated hosts in production, with about 4 GB of RAM each. A recovered replica resyncs automatically from a healthy peer. Replication does not protect against human error, so BACKUP and RESTORE jobs must run to separate storage, and the backup documentation advises regular restore tests on a spare cluster. Upgrades need a pre-production environment, and the production FAQ recommends reading the changelog because minor backward-incompatible changes can occur. Ask for an estimate that covers monitoring, on-call, upgrade cadence and restore testing, not only installation.
Can our own team run this, or do we need outside help?
Your team can run either system if it already operates PostgreSQL or ClickHouse in production and has time for upgrades, restore drills and on-call. The skills that matter are SQL performance tuning, backup verification, identity integration and capacity planning. Check three things honestly: whether someone owns each component, whether restore tests happen on a schedule, and whether the release cadence fits your change process. DeployOpen plans, implements, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms in your own infrastructure, typically under a fixed-scope agreement with ongoing support available as a retainer. Ask any provider for the written scope, the named deliverables and what remains your responsibility after handover.
How DeployOpen helps you choose and run either platform
Whichever platform fits your workload, the hard part is the same: planning the layout, hardening it, backing it up and keeping it upgraded inside your own infrastructure. DeployOpen does not favor ClickHouse or TimescaleDB, and every engagement starts from a written scope that a quote follows from.
Fixed-scope planning and sizing
Before anything is installed, the scope should settle whether data stays in PostgreSQL or moves to a separate ClickHouse server, which query shapes matter, and how much retention and write volume the platform must absorb. DeployOpen plans that scope in writing with you, including the test workload you will use to compare both options on your own data. Ask for the deliverables and timelines to be listed explicitly before work starts.
Implementation inside your infrastructure
DeployOpen installs and configures the chosen platform in your cloud accounts, data centers or air-gapped networks. For TimescaleDB that means the extension, hypertables and Community Edition features on your PostgreSQL. For ClickHouse it means server configuration, replication and coordination layout. Confirm which edition, license terms and hosting model apply before the design is signed off.
Hardening and access controls
Authentication and authorization need deliberate choices on either side. ClickHouse supports LDAP, Kerberos, X.509 certificates, an HTTP authenticator and JWT as external authenticators. PostgreSQL offers password, GSSAPI, LDAP, certificate, PAM and OAuth methods. DeployOpen configures the method your identity provider supports and documents it for your auditors.
Backup, restore testing and recovery
Replication does not protect against human error or corruption, so both platforms need separate backups and tested restores. ClickHouse BACKUP and RESTORE write to local disk, S3-compatible storage or Azure Blob Storage. PostgreSQL relies on continuous archiving and point-in-time recovery. DeployOpen designs the backup schedule and runs restore tests on a spare environment, which is the step most teams skip.
Upgrade and version management
Upgrade paths differ. ClickHouse ships stable releases roughly monthly and LTS releases twice a year, while PostgreSQL ships one major version a year and supports each for five years. DeployOpen plans the upgrade calendar, rehearses changes in a pre-production environment and reads changelogs for backward-incompatible changes before each move. Confirm the version your support window requires.
Compliance evidence preparation
Assessors ask for configuration baselines, access records, backup logs and restore test results. DeployOpen prepares those systems, controls and evidence so your team can hand them to an independent auditor or certification body. DeployOpen does not issue audit reports, attestations or certifications, so confirm with your assessor which artifacts they need before the build starts.
