ClickHouse vs StarRocks: when each one fits your analytics workload
If your team is shortlisting self-hosted OLAP for customer-facing analytics and joins, the decision turns on four things: how join-heavy your queries are, whether you need to query data that already lives in a lakehouse, which storage model you want, and what your operators already know how to run. ClickHouse fits teams that want one column store, replicated through ClickHouse Keeper, and are willing to own a documented backup and restore discipline. ClickHouse keeps data in its own MergeTree tables, so the storage layer is one system to size, upgrade and back up.
StarRocks fits teams that need MySQL protocol access, shared-data mode on object storage, or direct queries against Hive, Iceberg, Delta Lake and Hudi. Its frontend (FE) and backend (BE) nodes, or stateless compute nodes in shared-data deployments, make it a better match when the lakehouse is the system of record and analytics should query it in place. Confirm which MySQL client and BI tool behaviors your product depends on, since protocol compatibility is not the same as feature parity.
Test with your own workload before committing. Run your heaviest multi-table joins, your concurrency peak and a restore from backup on a pre-production cluster that holds representative data. (Illustrative: if most of your dashboards join two large fact tables against small dimensions, measure that exact pattern on both engines rather than relying on general benchmarks.) Also confirm the team can run Keeper quorums, object storage caching and the chosen upgrade cadence, because the operating skills needed differ more than the feature lists suggest.
Which platform fits which scenario
This table maps common workloads to the platform that usually fits better and names the condition under which the other one would win. Read each row as a starting hypothesis to test against your own data, concurrency targets and team skills, not as a verdict.
| Scenario | Better fit and reason | When the other platform wins |
|---|---|---|
| Customer-facing dashboards with high concurrency on wide, denormalized tables | ClickHouse, because its columnar MergeTree engine is built for scanning and aggregating large single-table datasets, and a single server model keeps the design simple for one fact table. | StarRocks may fit better if the dashboards also need frequent upserts and deletes through its primary key model, or if you expect to run many tenants in one cluster with resource isolation. |
| Join-heavy reporting across many normalized tables | StarRocks, because its MPP engine and optimizer are designed around multi-table joins, and its README claims full TPC-H and TPC-DS support, which you should validate against your own schema. | ClickHouse may fit if you can denormalize the joined tables into wide tables ahead of time, which keeps query paths short and the operating model simpler. |
| Lakehouse query layer over existing Iceberg or Hudi data | StarRocks, because it queries Hive, Iceberg, Delta Lake and Hudi tables in place without importing them, so the data stays in your open table format. | ClickHouse may fit if you want to load a curated subset into its own storage for low-latency serving, and confirm current lakehouse connector support in its documentation first. |
| MySQL-speaking BI stack already in place | StarRocks, because it is compatible with the MySQL protocol, so existing MySQL clients and BI tools can usually connect with little change. | ClickHouse may fit if your BI tools already support its native interfaces or drivers, and you are willing to validate those connections and SQL dialect differences. |
| One server model with Keeper-based replication | ClickHouse, because replication runs through ReplicatedMergeTree tables coordinated by ClickHouse Keeper, a single database engine with one operational model to learn. | StarRocks may fit if you want to separate frontend and backend roles explicitly, and your team is ready to run FE and BE nodes and their leader and follower layout. |
| Compute separated from object storage | StarRocks, because its shared-data mode keeps data in object storage such as S3, GCS, Azure Blob Storage or MinIO, with stateless compute nodes and a tiered cache. | ClickHouse may fit if your object storage strategy is limited to backups, or you prefer local-disk storage with replicas and the operating model you already validated. |
How ClickHouse and StarRocks are built and deployed
ClickHouse and StarRocks reach real-time analytics through different building blocks. ClickHouse keeps storage and replication on each server and relies on a Keeper quorum for coordination, while StarRocks splits metadata, query planning and data handling across frontend and backend roles, with an optional shared-data mode on object storage.
MergeTree and replicated tables
ClickHouse stores data in MergeTree tables, and replicated tables use the ReplicatedMergeTree engine so that each replica holds its own copy of the data. Replication is set per table, so teams need to decide which tables must survive a server loss and which can be rebuilt. Day-two work includes watching replica health and merge backlog. A recovered replica automatically syncs missing data from a healthy replica, but replication does not protect against human error or corruption, so backups remain a separate job. Confirm which tables your team will replicate before you size the cluster.
ClickHouse Keeper quorum
ClickHouse Keeper coordinates ReplicatedMergeTree replicas and replaces ZooKeeper in the ClickHouse stack. The replication guide recommends at least three Keeper nodes on dedicated hosts in production, with about 4 GB of RAM each. Keeper is an extra tier you must patch, monitor and back up alongside the database servers. Losing quorum stops coordination for replicated tables, so the reader should plan host placement, failure domains and monitoring for Keeper before the first production load.
StarRocks FE and BE roles
In shared-nothing deployments, StarRocks frontend (FE) nodes manage metadata, client connections, query planning and scheduling, and run as leader, follower or observer. Backend (BE) nodes both store data and compute queries. Scaling compute usually means scaling BE nodes, which also moves data, so capacity changes carry storage rebalancing. Day-two teams watch FE leader health and BE disk and tablet balance. Confirm the FE and BE node counts and disk layout your workload needs, since these shape both recovery time and upgrade sequencing.
Shared-data mode with CN nodes
In shared-data deployments, stateless compute nodes (CNs) run queries and cache data while the data itself sits in object storage such as AWS S3, Google GCS, Azure Blob Storage, MinIO or HDFS. The README states shared-data architecture is supported from version 3.0. Compute nodes can be added or removed without moving data, but object storage access, credentials and latency become core dependencies. Confirm your object store, network path and credential rotation process before choosing this mode, because storage outages affect every query.
Tiered cache in shared-data mode
Shared-data mode uses a tiered cache across memory, local disk and remote storage. Hot data is read from cache, and cold data is loaded from object storage into the local cache on demand. Query latency therefore depends on cache hit rates, which change with workload shape and cache sizing. Teams should test representative dashboards against cold cache, measure the first-query penalty after a node restart, and confirm how cache capacity is set on each compute node before promising response times to customers.
Kubernetes operator and upgrades
StarRocks maintains an Apache-2.0 Kubernetes operator in its own GitHub repository, which is the supported route for teams that run StarRocks on Kubernetes. ClickHouse has no equivalent operator in the supplied sources, so teams deploying on Kubernetes should confirm which operator or packaging they will use and who maintains it. Either way, plan upgrade order, stable versus LTS tracks and a pre-production environment with representative data, since minor releases can contain backward-incompatible changes.
ClickHouse vs StarRocks on the capabilities that decide the choice
This table compares ClickHouse and StarRocks on the capabilities that usually settle a shortlist for customer-facing analytics and joins. Read each row as a question to answer for your own workload, and confirm the rows marked for vendor confirmation before you commit.
| Capability | ClickHouse | StarRocks |
|---|---|---|
| License | Apache-2.0 for the ClickHouse server. ClickHouse Inc. separately sells ClickHouse Cloud as a managed service. | Apache-2.0. Describes itself as a Linux Foundation project. |
| Governance | Maintained by ClickHouse Inc., which also sells the managed cloud. Confirm the contributor base and roadmap process with the vendor. | Linux Foundation project. Confirm current governance documents and maintainer mix in the repository before relying on them. |
| SQL and protocol compatibility | Column-oriented SQL database. Check the dialect and client driver support against your existing BI tools and applications. | Supports ANSI SQL and is compatible with the MySQL protocol, so MySQL clients and BI tools can connect. |
| Lakehouse access | Confirm which table formats and catalogs your version reads directly with the vendor before relying on them. | Queries Apache Hive, Apache Iceberg, Delta Lake and Apache Hudi directly without importing the data. |
| Update model | Confirm the update and delete semantics of your table engine with the vendor for your access pattern. | Primary key model with upserts and deletes, which fits data that changes after load. |
| Materialized views | Confirm the materialized view behavior and refresh model for your version with the vendor. | Materialized views refresh during data import and are selected automatically at query time. |
| Object-storage mode | Confirm the object-storage and tiered options for your deployment model with the vendor. | Shared-data mode on object storage such as S3, GCS, Azure Blob Storage, MinIO or HDFS, supported from version 3.0. |
| Replication and coordination | ReplicatedMergeTree tables coordinated by ClickHouse Keeper. Production guidance recommends at least three Keeper nodes on dedicated hosts. | Frontend and backend node roles with shared-nothing or shared-data deployments. Confirm the replica and failover model for your topology with the vendor. |
| Backup options | 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. | Confirm backup and restore tooling, and whether snapshots cover shared-data storage, with the vendor. |
| External authentication | LDAP, Kerberos, SSL X.509 certificates, an HTTP authenticator and JWT authentication as external authenticators. | Confirm supported external identity methods, such as LDAP or SSO, for your version with the vendor. |
Licensing, governance and editions for each platform
The ClickHouse server is open source under the Apache License 2.0, as shown in its GitHub repository. ClickHouse Inc. separately sells ClickHouse Cloud as a managed service, so the decision to buy the managed service is separate from the decision to run the server on your own infrastructure. Your license review should cover the server code you deploy and any terms that apply to the managed offering.
- Server license: The server carries the Apache-2.0 license. The supplied facts do not list enterprise-only server features, so confirm in writing which capabilities you need are in the open-source build.
- Stable line: Version 26.9 is the current stable line, with v26.9.20.23-stable marked as latest. Stable releases ship roughly monthly, and the production FAQ recommends them for most production use after testing in a pre-production environment.
- LTS lines: The 26.8 and 26.3 lines are published as LTS, with v26.8.29.10-lts and v26.3.53.4-lts dated October 16, 2026. LTS releases ship twice a year and are supported for a year after release, so check the release date of your exact line before you commit to it.
- Security support: The ClickHouse security policy lists 26.9, 26.8, 26.7 and 26.3 as receiving security updates. Every other version is unsupported, so any cluster on an older line needs an upgrade plan.
Before you standardize on a line, check the security policy and release page on the day you plan the upgrade, and ask ClickHouse Inc. in writing whether paid support exists for self-hosted deployments.
StarRocks is licensed under the Apache License 2.0 and describes itself as a Linux Foundation project, according to its GitHub README. Foundation hosting gives the project a neutral governance framework, but the README does not describe a commercial edition. Treat paid support and enterprise features as open questions until the vendor answers them in writing.
- License terms: The project is Apache-2.0. Read the LICENSE file and any contributor terms in the repository before you build a product or internal platform on it.
- Foundation status: The README identifies the project as a Linux Foundation project. Ask how roadmap decisions are made and which party controls releases, because a foundation label alone does not describe the day-to-day governance you will depend on.
- Current release: StarRocks 4.1.3 was published on September 17, 2026, according to the releases page. The supplied facts do not give a support window for this line, so ask which minor versions receive patches and for how long.
- Kubernetes operator: The operator repository is maintained under Apache-2.0. Match its release tags to the database version in your plan and confirm the compatibility matrix with the maintainers before deployment.
Request the written support and security patch policy for the version you intend to run, and confirm whether an enterprise distribution exists before your cost model assumes one.
Neither platform's supplied facts list paid support plans, enterprise feature gates or service-level commitments. These questions belong in the procurement file for both products, because they decide which parts of your design are free to run and which must be bought. Ask each vendor or project the same questions so the answers are comparable.
- Feature gates: List every feature your design depends on, including authentication, backup, replication and any managed-service dependency. Ask which of these are in the open-source build and which need a paid edition or cloud service.
- Support windows: Get the end-of-support date for the exact version in your plan. For ClickHouse, the policy and LTS cadence give a starting point. For StarRocks, the answer must come from the project or a commercial provider.
- Governance and roadmap: Record who controls releases, how security fixes are published and whether contributor terms affect redistribution. A company-backed or foundation-hosted project can change its roadmap, so keep this decision on the record.
- Upgrade and rollback: Ask what each upgrade path flags as backward-incompatible and whether a rollback path is documented. ClickHouse's production FAQ warns that minor backward-incompatible changes can occur, so ask StarRocks for the same statement.
Write the answers into the quote scope so that licensing, support and upgrade work is documented before implementation begins.
What drives the running cost of each cluster
The running cost of either cluster is mostly infrastructure, but the line items differ. A ClickHouse cluster is paid for in servers or cloud instances for the shards and replicas, local disks sized for the data, and Keeper hosts. The replication guide recommends at least three Keeper nodes on dedicated hosts in production, each with about 4 GB of RAM, so a replicated layout pays for coordination capacity that a single server does not need. A StarRocks cluster has a different split. Frontend nodes handle metadata and planning, and backend nodes in shared-nothing mode both store and compute. In shared-data mode, stateless compute nodes run queries and cache data while object storage holds the data. Your largest variable there is cache sizing: the tiered cache across memory and local disk determines how often queries fall through to object storage, so confirm the cache footprint with a load test on your own query mix rather than assuming it. Backup storage and restore testing are recurring costs that are easy to undercount. ClickHouse BACKUP and RESTORE can write full and incremental backups to local disk, S3-compatible storage or Azure Blob Storage, and the backup documentation notes that replication alone does not protect against human error or corruption. Those backups need retention space. The documentation also warns that a backup never test-restored will probably not restore when needed, so a restore test cluster, or spare capacity to run one on a schedule, is a cost you should budget for explicitly. Staff time is the other large recurring line. Running either system in production means someone owns upgrades, on-call response and capacity reviews. ClickHouse stable releases ship roughly monthly, and the security policy lists 26.9, 26.8, 26.7 and 26.3 as supported, so the upgrade cadence you choose sets how often that work recurs. One-time costs cluster around design, migration and load testing: schema and table design, data migration, benchmark runs against your own queries and the initial hardening and documentation. Vendor support is optional and priced by the vendor, so confirm what each option includes with the vendor directly. When requesting a quote from DeployOpen, ask for a written scope that names each environment (production, pre-production with representative data, and restore test), the restore test plan with its frequency and success criteria, the upgrade policy and which release lines it covers, the Keeper or frontend and backend node counts, and which costs are one-time and which recur. Ask how cache sizing and storage growth were assumed, so you can compare the two clusters on the same basis.
Moving analytics from one platform to the other
This sequence moves analytical workloads between ClickHouse and StarRocks in an order that keeps query results verifiable at each stage. It ends with a cutover decision based on your own data and queries, not on a generic benchmark.
Inventory queries and BI connections
Your data engineers and BI owners list every query, dashboard, scheduled job and application connection that reads from the current platform, with its owner, refresh schedule and latency target. Note which clients connect over the MySQL protocol, since StarRocks supports that protocol and most BI tools that speak MySQL can connect to it, and confirm the same for ClickHouse's client drivers and HTTP or native interfaces for your specific tools. The step is done when every consumer has an owner and a classification as keep, rewrite or retire.
Map table models and update patterns
Data engineers translate each table into the target model. ClickHouse uses MergeTree-family engines with sorting keys, while StarRocks offers a primary key model with upserts and deletes, so tables that depend on row updates or deletes need explicit design rather than a direct copy. Record the sorting or primary keys, partitioning, and how late or duplicate events are handled. The step is done when a written mapping exists for every table and each update pattern has a named target construct.
Decide on loading or lakehouse access
The architecture lead decides, per dataset, whether data is loaded into the engine's native storage or left in place. StarRocks can query Hive, Iceberg, Delta Lake and Hudi directly, and ClickHouse-side lakehouse access should be confirmed against the version you plan to run. Shared-data mode on object storage is a separate decision with its own cache sizing, so confirm your object storage and cache requirements before choosing it. The step is done when each dataset has a documented load path or external-access path.
Rebuild materialized views and resource isolation
Engineers recreate pre-aggregations and materialized views on the target platform and confirm they refresh correctly under your ingest pattern. StarRocks materialized views refresh during data import and can be selected automatically at query time, so verify that behavior against your own queries. Tenant isolation is rebuilt with the target's resource controls, using StarRocks resource management or ClickHouse settings and quotas as applicable. The step is done when each view returns the same results as its source query on a test window.
Rebuild authentication, replication and backups
Security and platform engineers recreate user accounts, roles and authentication on the target. ClickHouse supports LDAP, Kerberos, X.509 and JWT through external authenticators, and StarRocks access control must be configured separately. Replication is rebuilt from scratch, since ClickHouse uses ReplicatedMergeTree with ClickHouse Keeper, and backup jobs are rewritten for the target tooling. Restore tests are scheduled from the first day, because a backup that has never been test-restored will probably not restore when needed. The step is done when a restore has succeeded on a spare cluster.
Run side-by-side query comparisons
Run both platforms in parallel on a copy of production data and replay representative queries, including joins, aggregations and BI dashboards. Compare results for correctness first, then latency and resource use under realistic concurrency, recording the settings and hardware used. Ask your platform team and the vendor to review the configuration before testing, and read the changelog for the version you plan to run, since minor backward-incompatible changes can occur. The step is done when mismatches are explained and the performance numbers are recorded from your own workload.
Cut over and retire the old platform
Move consumers in waves, starting with lower-risk dashboards, and keep the previous platform read-only for a rollback window agreed in advance. Monitor query errors, latency and data freshness after each wave, and confirm the replication and backup jobs on the new platform are running. Retirement of the old system happens only after the agreed window closes with no open defects. The step is done when all consumers are on the target, rollback has been tested, and the old platform's decommissioning record is signed off.
Where implementation projects usually run long
Implementation projects on either platform usually run long at the schema and test stage, not at installation. On ClickHouse, the early decisions are the table engine and sort keys for each MergeTree table, plus the Keeper layout. Keeper should run as at least three nodes on dedicated hosts with about 4 GB of RAM each, according to the ClickHouse replication guide, and that sizing must be settled before the first replicated table is created. Projects also overrun when the test data is a small sample that does not match production cardinality or skew. Load a copy of representative data and run the dashboard queries your users will actually send, not a benchmark suite. Plan a backup and restore cycle early, and schedule restore tests on a spare cluster, because the ClickHouse backup documentation warns that a backup never test-restored will probably not restore when needed. Review the changelog before each upgrade, since minor backward-incompatible changes can occur.
StarRocks projects carry their own long pole in the data model and the topology. Teams must choose between a shared-nothing layout, where BE nodes both store and compute, and a shared-data layout, where stateless CN nodes cache data pulled from object storage such as S3 or MinIO. Each choice changes how the FE leader, followers and observers are sized and how the local cache is tuned for hot data. Resource isolation for tenants in one cluster also needs to be designed before BI teams arrive, not after. Confirm the query shapes from your BI tools early. Joins and wide dashboard filters often behave differently from the TPC-H and TPC-DS results that vendors publish, so test those shapes directly. Identity integration is the final common overrun on both platforms: LDAP, Kerberos or JWT access for ClickHouse, and the MySQL-protocol user model for StarRocks, should be wired to your directory in the first sprint, because changing authentication after dashboards and service accounts exist is expensive.
Questions buyers ask before choosing ClickHouse or StarRocks
What drives the cost and effort of running ClickHouse or StarRocks?
The main cost is people, not licenses, because both engines are Apache-2.0 open source and you pay for servers, storage and the staff or partner who build and run the cluster. For ClickHouse, the largest drivers are the number of replicas and shards, the Keeper quorum (the replication guide recommends at least three Keeper nodes on dedicated hosts with about 4 GB of RAM each), backup storage and restore testing. For StarRocks, the main choice is shared-nothing (FE and BE nodes that store and compute) or shared-data (stateless compute nodes over object storage such as S3, GCS, Azure Blob Storage, MinIO or HDFS), which changes both hardware and operating work. Recurring costs include upgrades, monitoring, on-call and capacity growth. Ask any quote to split one-time build work from recurring operations, and to name who owns each node role and each backup job.
How long does a typical ClickHouse or StarRocks implementation take?
No fixed duration applies to every environment, so treat any single number with caution. The time depends on data volume, the number of query shapes that must be proven, how many sources feed the cluster, whether the layout is single-node, replicated or shared-data, and how much of the security and backup work is new to your team. For ClickHouse, a replicated layout adds Keeper design, replica testing and a backup and restore test on a spare cluster, which the backup documentation recommends. For StarRocks, the choice of storage mode, the update model and any lakehouse connections add design steps. DeployOpen agrees timelines in a written, fixed scope before work starts, so ask for the schedule to be tied to named deliverables and milestones.
What does the work need from our own team?
Your team needs people who can own the database after handover, so plan for skills in Linux operations, networking, storage, identity, and SQL performance tuning. On the ClickHouse side, expect someone to own replication health, Keeper nodes, version upgrades (the production FAQ recommends reading the changelog first because minor backward-incompatible changes can occur) and restore tests. On the StarRocks side, expect ownership of FE leader and follower placement, BE or compute node capacity, cache sizing in shared-data mode and the Kubernetes operator if you use it. You also need data engineers who know your sources and BI users who will connect through SQL or the MySQL protocol. Confirm the named owners and their time commitment in the scope document.
Can our team run ClickHouse or StarRocks without outside help?
A capable infrastructure team can run either engine, but the answer depends on whether it has operated a distributed database before and whether it will carry the on-call load. Both are self-hostable, and ClickHouse documents its replication, backup and access control behavior in detail. The risk areas are the ones documentation cannot settle for you: sizing for your query mix, proving that backups restore, handling upgrades across monthly stable and twice-yearly LTS releases, and securing access with the authenticators your directory supports. If your team is short on these skills, DeployOpen can plan, implement, harden, back up, document and support the platform inside your infrastructure, with ongoing support available as a retainer. Ask for a written scope that separates the handover tasks from the retainer tasks.
How do we test ClickHouse and StarRocks on our own data before committing?
Build a pre-production environment with representative data volumes, your real query shapes, your joins and your concurrency pattern, then measure both engines against the same workload. The ClickHouse production guidance recommends this kind of pre-production test with representative data and queries. For StarRocks, include the MySQL-protocol clients and BI tools your users will run, and test any direct queries over Hive, Iceberg, Delta Lake or Hudi that you expect. Run a restore test for every backup method you plan to use, since an untested backup is unlikely to restore when needed. Record latency, resource use, operational steps and failure behavior, not just speed. Define pass criteria in writing before the test so the decision rests on your evidence.
Which engine has the clearer licensing and governance position?
Both server codebases are licensed under Apache-2.0, so the core engine terms do not separate them. ClickHouse server is open source under Apache-2.0, and ClickHouse Inc. sells ClickHouse Cloud as a managed service. StarRocks is Apache-2.0 and describes itself as a Linux Foundation project, and it maintains an Apache-2.0 Kubernetes operator. Check governance with your legal and procurement teams, including who controls the roadmap, how release branches are maintained, and what support windows apply to the version you pick. For ClickHouse, the security policy currently lists 26.9, 26.8, 26.7 and 26.3 as supported, so confirm which line you will run against that policy before you build on it.
Who should we ask for a quote, and what should it include?
Ask for a quote built from a written scope, not a per-seat or list price, because DeployOpen does not publish a price list and quotes follow from the agreed scope. The quote should name the architecture (single-node, replicated ClickHouse, shared-nothing or shared-data StarRocks), the number of environments, the data sources, the backup and restore tests, the security hardening, the documentation and the handover plan. It should separate one-time implementation from any recurring retainer for support, upgrades and continuous testing. Ask what is excluded, such as hardware, cloud accounts, object storage fees and third-party licenses, since those are paid to other vendors or providers.
How DeployOpen helps teams choose, implement or migrate
DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For ClickHouse vs StarRocks, we start with the workload and the team that will run the cluster, then build only what the agreed scope requires.
How we scope
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- We document the query shapes, join patterns, concurrency targets and data volumes the cluster must serve.
- We record which deployment layout is in scope, such as replicated ClickHouse with Keeper or StarRocks shared-data on object storage.
- We confirm license, edition and feature requirements against the vendor's current terms before selection is final.
How we build
- We deploy the chosen engine in your environment, with the coordination, storage and network design written down.
- We configure authentication, including LDAP, Kerberos, certificates or JWT for ClickHouse, or the MySQL-protocol access controls for StarRocks.
- We run pre-production tests on representative data and queries, so you see behavior on your own workload.
- We integrate your BI tools and ingestion pipelines, and test them against the cluster before cutover.
How we hand over
- You receive architecture notes, configuration records and runbooks for upgrades, scaling and incident response.
- We set up backup and restore procedures and run a documented restore test on a spare cluster before handover.
- We walk your platform and security teams through access controls, monitoring and the upgrade approach.
- Compliance evidence, where your program needs it, is prepared for your independent auditors to assess.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- We track vendor release and security notices, then plan upgrades against the changelog and a pre-production run.
- Retainers can cover periodic restore tests, capacity reviews and changes to query workloads over time.
- Ask us to confirm support windows and upgrade paths for the exact versions you select before you commit.
