Altinity.Cloud BYOC: An Evaluation and Migration Guide

Altinity.Cloud BYOC places a managed service for ClickHouse® in your cloud account. That can make infrastructure ownership and data placement easier to align with an existing platform, but it does not make a production migration a single provisioning step.

TL;DR

• Agree who owns access, networking, database changes, incidents and recovery before starting an Altinity.Cloud BYOC trial.
• Evaluate representative reads and writes together, including ingestion freshness, background merges and complete service cost.
• Plan an initial copy plus catch-up for ongoing changes, then validate application results and rehearse a restore.
• Cut over in stages and define how rollback will reconcile any writes accepted by the new environment.

The evaluation should produce four concrete results: an agreed responsibility split, a representative workload comparison, a demonstrated restore, and a reversible cutover. This guide follows that sequence, with the Nirvana deployment path and the operational evidence to collect at each stage.

Primary documentation reviewed 7 October 2026. The SQL examples and acceptance process are proposed evaluation tools, not results from a newly executed customer benchmark.

What changes when you choose BYOC?

In Altinity's BYOC model, scoped access lets Altinity provision and manage resources in your cloud account. BYOK is a different boundary: you bring an existing Kubernetes environment. Select the model first because it determines which infrastructure work remains with your team.

Use the responsibility documentation as a starting point and agree the details for your deployment. The following is an evaluation agenda, not a substitute for a service agreement:

For Nirvana, Altinity's remote-provisioning guide describes creating a project and API key, then selecting Nirvana Labs and BYOC in the Altinity environment setup. Follow the current permission requirements and handle the credential through the supported setup flow. Keep secrets out of benchmark scripts and evaluation reports.

Provisioning proves that an environment can be created. The remaining steps prove whether it is suitable for your application.

How do you build a representative workload comparison?

Inventory the source before sizing the target: database version, table engines, partition and ordering keys, codecs, materialized views, dictionaries, users, ingestion clients and downstream readers. Include data age and skew. A uniform synthetic dataset may miss a hot tenant or a recent partition that dominates production traffic.

Choose a trace with both reads and writes. Preserve query mix, concurrency, insert batch size and arrival pattern. Run long enough to observe background work and storage growth, not only an initial read-only burst. Record target configuration and any changes to settings or schema.

ClickHouse's query log exposes execution duration, read volume and memory use. This illustrative query groups successful SELECTs on the current node by normalized query shape:

SELECT
    normalized_query_hash,
    count() AS executions,
    quantileExact(0.50)(query_duration_ms) AS p50_ms,
    quantileExact(0.95)(query_duration_ms) AS p95_ms,
    sum(read_bytes) AS read_bytes_total,
    max(memory_usage) AS peak_query_memory
FROM system.query_log
WHERE event_time >= now() - INTERVAL 1 HOUR
  AND type = 'QueryFinish'
  AND query_kind = 'Select'
GROUP BY normalized_query_hash
ORDER BY executions DESC;

Check logging configuration and the correct node or cluster scope before interpreting it. This query excludes failed operations; collect failures separately. Server execution time also excludes parts of the client experience, so retain client-side latency and correctness results.

Inspect ingestion health alongside reads. The system.parts table exposes active parts, row counts and bytes on disk; system.merges describes current merge work. Track the trend during the test. A fast query sample is less useful if parts accumulate without reaching a sustainable operating state.

Write the acceptance criteria before testing: required query latency at the expected concurrency, ingestion freshness, acceptable error rate and complete service cost. Include compute, storage, backup retention, transfer and the managed-service charge. Compare the same scenario on each environment.

What should the Nirvana infrastructure trial establish?

Keep the dataset and application behavior fixed when changing infrastructure. Check placement relative to producers and readers, private network paths, resource sizing and the storage headroom needed while ingestion and merges are active.

A published storage benchmark can suggest a test hypothesis. It cannot establish that every query in your schema will improve. Evaluate the actual mix: selective reads, wide scans, joins, recent-data queries and writes under concurrency. Report regressions and failures alongside improvements.

For a concrete example, an event analytics system might satisfy its quiet-period dashboard queries but miss its freshness target during a burst of small inserts. The useful experiment preserves that burst and observes ingestion delay, part growth and query latency together. Changing the batch size only on the candidate would confound the comparison unless it is documented as a separate application optimization.

Repeat the workload after a restart or recovery rehearsal. Users experience the service when caches are cold and background work is catching up, not only after a favorable warm-up. Keep those results separate from steady-state operation.

How do you move data and prove that recovery works?

Altinity's Copy Data Wizard supports selecting source and destination clusters and the tables to copy. An initial copy is only one part of a live migration. Agree how new writes, late events, deletes and schema changes will be handled while the source remains active.

Define a source watermark for the copy and a catch-up mechanism. Validate by partition or time interval, not only one total row count. Compare representative aggregates, recent event IDs and business queries. For engines with special merge semantics, agree which query represents the application's logical result before comparing totals.

Then rehearse a restore. Altinity documents manual and scheduled backups, cluster-level schedule overrides and restore cases that involve support. Confirm the workflow and service dependency for your intended scenario rather than assuming every restore is self-service.

Use a fresh test target and measure from the decision to restore until the application passes its validation queries. Record the actual recovered point, elapsed time, missing prerequisites and who performed each step. A successful backup job is not a substitute for that exercise.

How do you cut over without making rollback ambiguous?

Start with a test reader or a small cohort of read traffic. Compare results with the source and inspect errors before increasing exposure. For the final switch, name the decision owner and define the ingestion pause or final catch-up boundary, reader endpoint change and observation period.

Rollback needs a data policy. If the target accepted new writes after cutover, switching the connection string back can lose those writes from the application's view. Decide how they will be replayed or reconciled, and prevent uncontrolled dual writers. Retain the source for an agreed window with an explicit owner and retirement condition.

Begin with an Altinity.Cloud trial and agree the evaluation scope. Then review the matching Nirvana infrastructure. The outcome should be a documented production decision, supported by your workload and a practiced migration path.

FAQ

Is BYOC the same as operating ClickHouse yourself?

No. Altinity provides a managed service for ClickHouse, while responsibilities for your account, application and selected infrastructure boundary remain explicit.

Can the initial data copy replace a catch-up plan?

Not when the source keeps changing. Define how writes and schema changes after the copy's starting point reach the target.

What is the most useful proof before cutover?

Correct application results under representative load, plus a demonstrated restore and a rollback procedure that accounts for new writes.

About Nirvana Labs

Nirvana Labs is a high-performance storage cloud purpose built for blockchain, AI and databases i.e. the most demanding, real-time, stateful workloads. Accelerated Block Storage (ABS) offers 20K baseline IOPS included, no over provisioning. Nirvana Kubernetes Service (NKS) with Karpenter auto-scaling, high clock-speed compute and private networking. Backed by Jump Trading, Crucible, etc with 50+ customers live in production today.

Learn more at Nirvana Labs

Nirvana Cloud | Pricing | Blog | Docs | Changelog | LinkedIn | Twitter | Telegram | YouTube