Which ClickHouse deployments can Renta write to?

Any deployment whose HTTP interface Renta can reach: a self-managed cluster, ClickHouse Cloud, or a managed service such as Yandex Managed Service for ClickHouse. For Yandex-managed hosts connected over **https**, Renta uses the Yandex root certificate automatically, so you do not need to upload anything.

Do I have to create the table in ClickHouse before the first run?

No. Renta issues **CREATE TABLE** on the first run and builds the column list from the fields selected in the pipeline. You only create the database and the user.

Why does a table in merge mode show two versions of the same row?

Merge-mode tables use the **ReplacingMergeTree** engine, which drops older versions during background merges rather than at insert time. Until the merge happens, both versions are stored. Query the table with **FINAL** or with **LIMIT 1 BY** on the merge key to always read the latest version.

What happens if I add or remove a field in the pipeline settings?

The column list changes, so on the next run Renta drops the table, creates it again with the new columns, and reloads the whole period set in **Date Range**. Data outside that period is not restored.

Can two pipelines write into the same table?

Each pipeline manages its own table and rewrites it on its own schedule. Two pipelines sharing a **Table name** overwrite each other, so give every pipeline a unique table name.

A run failed with a message about an unauthorized remote URL. What does it mean?

The ClickHouse server refused to read the staged Parquet files because storage.googleapis.com is not in the remote_url_allow_hosts section of its config. Add the host to that section or remove the section entirely.

ClickHouse destination

Renta replicates data from any connected source into your ClickHouse database. It automatically provisions the destination table during the initial run and continuously synchronizes its contents on subsequent runs.

Each pipeline manages a single destination table. Renta extracts records, stages them as Parquet files within its cloud storage infrastructure, and instructs your ClickHouse server to ingest these files directly via HTTPS.

Requirements

Data transfer requires bidirectional communication. A firewall configuration that permits only unidirectional traffic may pass the initial connection test but will fail during pipeline execution.

HTTP interface accessibility.
Renta issues queries to the ClickHouse HTTP interface (default ports: 8443 for HTTPS, 8123 for HTTP). Ensure inbound access is allowed from the Renta IP addresses.
Storage accessibility.
ClickHouse downloads staged Parquet files from storage.googleapis.com via HTTPS. If your server configuration utilizes the remote_url_allow_hosts section, you must include this hostname.
Dedicated user privileges.
Renta requires permissions to create, populate, truncate, and drop tables within a designated database, as well as read external files utilizing the url table function.

ClickHouse user for Renta

GRANT statements for a dedicated account.

Connect the destination

A connection configuration defines the endpoint of a specific ClickHouse database and the corresponding authentication credentials required for Renta.

Connect ClickHouse as a destination

Follow these steps to add your ClickHouse database as a destination in Renta.

Go to the CatalogStep 1

In the Renta console, open Connections > Catalog in the left sidebar.
Expand the Data warehouse category and click the ClickHouse card.

ClickHouse card in the Data warehouse category of the Renta connection catalog

Enter the server addressStep 2

Provide the database connection details:

Server hostname.
The fully qualified hostname including the protocol such as https://clickhouse.example.com. Renta defaults to http:// if the protocol is omitted.
Database name.
The target database for your tables. Renta requires this database to be pre-created and restricts all write operations to it.
Port.
The HTTP interface port. Defaults are 8443 for HTTPS and 8123 for HTTP.

Add a new ClickHouse connection page with the server hostname, database name, and port fields

Enter the credentialsStep 3

User.
The ClickHouse username designated for Renta's operations.
Password.
The password associated with the specified user.

Authentication is performed exclusively via the HTTP interface. Access to the native ClickHouse protocol is not required.

User and password fields on the Add a new ClickHouse connection page

Name the connection and saveStep 4

Specify a Destination name (an internal label for the Renta console) and click Save.

Upon saving, Renta executes a diagnostic query against the specified database. Invalid credentials, closed ports, or non-existent databases will return immediate validation errors prior to pipeline execution.

Destination name field and the Save button on the ClickHouse connection form

Verify the connectionStep 5

The connection will appear in the Destinations list with an Active status, indicating it is ready for pipeline integration.

Destinations list with the new ClickHouse connection in the Active status

Create a pipeline

A pipeline establishes a data flow between a specific source and your ClickHouse connection. The following instructions demonstrate the configuration using Stripe, but the methodology applies universally across all supported sources.

Create a pipeline into ClickHouse

Link a data source to your ClickHouse database and configure the pipeline.

Select the sourceStep 1

Navigate to New pipeline in the left sidebar. Ensure the ETL tab is active, select a source from the Already connected section, and proceed by clicking Next step.

Select a source step of the pipeline wizard with the ETL tab and the Stripe card selected

Select the source connectionStep 2

Select the desired source connection for data extraction and click Next step.

Select your connection step with one source connection card

Select ClickHouse as the destinationStep 3

In the Destination stage, choose ClickHouse from the Already connected list and click Next step.

Select a destination step with ClickHouse under Already connected

Select the destination connectionStep 4

Select the target ClickHouse connection for data ingestion and click Next step. Connection cards display the database name and host to facilitate identification within workspaces managing multiple clusters.

Select your ClickHouse connection step with the database name and host on the card

Pipeline configuration

The final configuration stage consolidates all pipeline settings within a single interface. Source-specific parameters are located at the top, followed by destination-agnostic settings.

Source settings

The initial section defines the extraction scope. The available parameters are source-dependent. Stripe configurations, for example, begin with the report type selection.

Report Types dropdown in the pipeline settings with Balance Transactions selected

Select the specific fields for extraction. Each chosen field maps to a column in the destination ClickHouse table. Unselected fields are excluded from the data transfer.

Parameters picker with all fields checked and the Unselect All link

Renta displays the resulting column name for each field within the destination table. Use Select All to include all available fields simultaneously.

Integration and table name

The subsequent section defines the nomenclature for the pipeline within Renta and the corresponding table in ClickHouse.

Integration name and Table name fields in the pipeline settings

Integration name.
The assigned display name for the pipeline within the Renta console.
Table name.
The target table created by Renta within the designated database. You may retain the auto-generated name or specify a custom identifier. Ensure each pipeline is assigned a unique table name, as pipelines rewrite their respective tables during execution.

Date range

The date range dictates the historical data volume ingested during the initial execution and establishes the boundary for manual historical backfills.

Date start.
The starting date of the extraction window.
Date end.
The ending date of the extraction window, which can be a static date or a dynamic boundary such as Today.

Initiating a manual Full refresh from the pipeline dashboard will re-ingest data for this entire specified duration.

Overwrite period

The overwrite period determines the retroactive window for data replacement during scheduled executions. This applies exclusively to time-series report types that generate partitioned tables.

Renta purges existing rows within the specified timeframe and re-inserts them with updated values. Selecting Without overwrite data preserves historical records and strictly appends new data generated since the previous execution.

Schedule

The schedule dictates the frequency of automated data synchronization. All configured times are processed in UTC.

Schedule type	Description
Manual	The pipeline runs only when triggered from the Renta console or through the API.
Daily	The pipeline runs once a day at the specified update time.
Interval	The pipeline runs at specified time intervals.
Cron Expression	The pipeline runs on a schedule defined by a cron expression.

For Daily schedules, specify the Update time (the precise execution start time), and subsequently click Create pipeline.

Update time dropdown and the Create pipeline button

Renta additionally supports programmatic execution via API triggers and integration with external orchestrators such as Apache Airflow, Dagster, and Prefect. Refer to the scheduling documentation for comprehensive implementation details.

The configured pipeline will be listed in the Pipelines interface under the ETL tab, displaying the associated destination table name, current execution status, and the volume of extracted records.

Pipelines list with the new integration and its ClickHouse table name

Destination table

Renta actively manages the destination table lifecycle, automatically rebuilding it to accommodate pipeline schema modifications.

Engine and keys

The utilized ClickHouse table engine is dynamically determined by the source's data synchronization methodology.

Sync mode	Engine	Keys
Full reload and overwrite window	MergeTree	Sorted by the `date` column (if present in the pipeline payload). Otherwise, the sorting key incorporates all non-nested columns.
Merge	ReplacingMergeTree	Both primary and sorting keys align with the source's merge key, such as the record `id`.

Renta implements table partitioning by date when the column is available and the report type permits. This partitioning strategy optimizes overwrite operations, allowing Renta to target specific days efficiently rather than rewriting the entire table.

Column names and types

Destination column nomenclature mirrors the field names defined in the pipeline settings. Renta normalizes identifiers by replacing . and : characters with underscores (_). The field fee.amount therefore translates to fee_amount.

Source value	ClickHouse type
Whole numbers	Nullable(Int32) or Nullable(Int64) for wide ranges
Fractional numbers	Nullable(Float32)
Text, JSON, and identifiers	Nullable(String)
Boolean flags	Nullable(UInt8)
Dates	Nullable(Date)
Timestamps	Nullable(DateTime)
Lists of values	Array(Nullable(T))
Nested records	Nested(...) with one subcolumn per field

All scalar columns are instantiated as nullable. Consequently, absent source values are ingested as NULL instead of default values such as zero or an empty string. The merge key is strictly enforced as a non-nullable column.

Schema changes

Modifying the pipeline's field selection necessitates a structural change to the table definition, as ClickHouse does not support in-place mutation of sorting keys.

Saving structural changes (adding or removing fields) will trigger a table recreation during the subsequent run. Renta will drop the existing table, instantiate a new schema, and initiate a full historical backfill based on the configured Date Range. Data outside this window will be permanently purged. Adjust the Date start parameter prior to saving to retain necessary historical data.

Sync strategy

The data synchronization methodology is governed by a combination of source capabilities and pipeline configurations.

Strategy	When Renta uses it	Description
Full reload	Report types without a date column, and any pipeline with an unpartitioned table	Renta executes a `TRUNCATE TABLE` command and re-ingests the entire dataset, ensuring the destination table reflects the exact source state at execution time.
Incremental	Report types with a date column and a partitioned table	Renta performs a targeted deletion of rows within the specified overwrite window utilizing partition keys, followed by re-insertion. Historical partitions preceding the window remain intact.
Incremental (merge)	Report types that support merge sync. The source documentation names them for every source	Renta extracts solely the mutated records since the prior execution and inserts them into a ReplacingMergeTree table, utilizing the record identifier as the key. Obsolete row versions are asynchronously purged during ClickHouse background merges.

ClickHouse and Google BigQuery are the only destinations where merge mode is available. Pointing the same source at another destination switches it to full reload.

Due to the asynchronous deduplication mechanics of ReplacingMergeTree, transient duplicate records may exist. To guarantee strong consistency during read operations on merge-mode tables, append the FINAL modifier to your queries or isolate the most recent row per key using the LIMIT 1 BY clause.

Troubleshooting

Renta standardizes ClickHouse API responses into a deterministic set of diagnostic messages. The following reference tables categorize these messages based on their context: connection configuration or pipeline execution logs.

When you save the connection

Initiating a save operation triggers a diagnostic query. Renta evaluates the response against the following known states.

Message	Cause	What to do
Specified incorrect access credentials for the Clickhouse server. Please verify the accuracy of the information.	Server hostname was entered without a protocol, so Renta cannot build a request URL. The wording mentions credentials, but the credentials are fine.	Put `https://` or `http://` in front of the host name and save again.
Authentication failed: password is incorrect, or there is no user with such name.	ClickHouse rejected the sign-in.	Retype User and Password. Confirm the account exists and works by sending any query to the HTTP interface outside Renta.
Invalid ClickHouse credentials.	ClickHouse refused the request as unauthorized.	Check the account for a readonly profile, an IP filter, or a quota that blocks it. The user also has to be allowed to connect from the Renta IP addresses.
ClickHouse server is unavailable.	Renta could not reach the HTTP interface. The host did not resolve, the port was closed, the connection was refused or timed out, or the server answered 404, 500, or 504.	Check Server hostname and Port, confirm the HTTP interface is running, and open the Renta IP addresses on the firewall.

During a pipeline run

Pipeline execution involves table manipulation and file ingestion, introducing potential failure vectors related to privileges, memory constraints, and disk capacity.

Message	Cause	What to do
Unable to connect to Clickhouse. Please verify the accuracy of the provided credentials.	The connection timed out.	Check the firewall and the current load. A saturated cluster times out the same way an unreachable one does.
ClickHouse server is unavailable.	The same set of transport failures as on the connection form: no DNS record, closed port, refused or aborted connection, or an answer of 404, 500, or 504.	Repeat the connection checks, and look at whether the host survived a restart, a scale-down, or an address change.
Access to Clickhouse is denied.	The HTTP interface answered 403 Forbidden.	Check that the account is not blocked and that its allowed-address list includes the Renta IP addresses.
Not enough privileges for added ClickHouse user.	The account is missing one of the table privileges Renta needs in the connected database.	Grant SELECT, INSERT, CREATE TABLE, DROP TABLE, TRUNCATE, and ALTER TABLE, as described on the ClickHouse user page.
The ClickHouse user does not have the 'READ ON URL' privilege required to load data from a remote URL.	The account cannot use the `url` table function, which is how Renta loads the staged Parquet files.	Run `GRANT READ ON URL TO renta`. Before ClickHouse 25.7 the statement is `GRANT URL ON . TO renta`.
Attempt to load data from an unauthorized remote URL into ClickHouse.	The `remote_url_allow_hosts` section of the server config does not list the storage host, so ClickHouse blocks the download with its error 491.	Add `storage.googleapis.com` to that section, or remove the section so every host is allowed.
You need to increase the memory limit as the current limit has been reached.	The server hit its memory limit while reading a Parquet file. Reading needs headroom above the size of the file itself.	Raise `max_memory_usage` for the account, or make the run smaller: fewer fields, a shorter overwrite window, a narrower date range.
The ClickHouse server is returning a NOT_ENOUGH_SPACE error.	The ClickHouse volume ran out of free disk space.	Free space or extend the volume, then run the pipeline again. Files loaded before the failure stay in the table, so rerun the same window rather than assuming the table is untouched.

Unrecognized ClickHouse responses are not exposed directly in the execution logs. They are abstracted as An error has occurred. Please contact the technical support team., devoid of underlying database specifics. Please engage Renta support if you encounter this generic error.

Frequently asked questions

Ready to get started?

Build your data pipeline today or get a personalized demo. Start free!

Need help?

Get expert support to ensure your project succeeds. We're here to help!

Feature requests?

Help shape our product! Share your ideas for new features and integrations.