Please email us on [email protected] to talk to our team about pricing.
Yes. For Run-In-Your-Own Account customers you automatically gain access to volume price tiers as the size of your managed service increases. For Run-In-Instaclustr-Account customers, volume discounts may be offered on a case-by-case basis.
Please contact us at [email protected] if you would like to discuss larger deployments with us.
Absolutely! A range of discounts is available to customers who commit to a minimum 12-month subscription with us.
It all depends on if you are running in our cloud provider account—we call this Run In Instaclustr Account (RIIA), or your own account—Run In Your Own Account (RIYOA).
- For RIIA we manage the underlying infrastructure costs so the price that you pay is all-inclusive (compute, bandwidth, and storage).
- For all RIYOA subscriptions, we charge you a service fee based on the size of your deployment for our managed services. You are responsible for your own cloud provider infrastructure costs.
A qualified Startup is a company that has less than US$1 million in annual revenue and has raised less than US$10 million in venture capital. Our terms are on our policies pages. You can learn more about the Instaclustr Startup Program.
Once on our infrastructure, this can be done in-place with no downtime. If you are using DSE-specific features then some code change to your application may be required.
The cluster can only be converted to the equivalent open source version. If an upgrade is required, it will happen as a separate step after the conversion.
Apache Cassandra 2.1.5 – 2.1.15
Apache Cassandra 2.1.9 – 2.1.17
Apache Cassandra 3.0.7 – 3.0.12
The conversion happens node-by-node (or rack-by-rack in large clusters). It requires each node in the cluster to be restarted, but there is no cluster downtime.
Instaclustr will work with you to manage the whole migration process.
There may be configuration changes required to your existing cluster to prepare for the migration. If this is the case, Instaclustr will guide you step by step through those changes to ensure the migration occurs smoothly.
It is different for every cluster.
Things that affect the duration of the migration:
- If the source cluster needs prerequisite configuration changes (customer must complete). The technical checklist helps to identify these.
- How much data there is to migrate
a. Number of nodes and DCs
b. Quantity of data per node
Rule of thumb (excluding config changes):
- small clusters can be migrated in 1-2 days
- large clusters 5+ days
Yes, migrating existing clusters is something we do all the time. We have published a blog post that outlines the steps required to complete the migration.
Running in the customer’s cloud provider account requires a contract and minimum size requirements—contact [email protected] for more information on this process.
Once you have a contract in place, it typically takes 2-3 business days to complete both sides of the setup. Our Technical Operations team will provide you with a detailed step-by-step guide, and support you through the process.
We support using your cloud provider account for any of our supported cloud providers.
The maximum amount of attached storage per node is 2TB. However, you must maintain disk utilisation <70% per node to allow for compactions. Our support will warn you when your nodes exceed 70%. Customers can view live and historical disk usage on the console.
The “resizable” family of instances support online resizing of processing capacity including up to 16 CPU and 122 GB of memory. To prevent a disk bottleneck, the “resizable large” family of nodes is provisioned with 3.6TB of EBS for maximum IOPS. The maximum support storage capacity per node for these nodes is 2GB (or 55%).