FAQs

A Shared Virtual Instances is not suitable for production workloads. Accounts with a Shared Virtual Instance share a global resource pool and isolation is not guaranteed. Your data is strictly kept isolated from other accounts but you share CPU and memory resources with other accounts. Sharing resources with other accounts allows you to utilize a lot of resources at a cost-effective price and is a great place to start using Rockset. A noisy neighbor can affect the latency and throughput of your queries. Bursty workloads from accounts may impact your query performance and availability.

A Shared Virtual Instance is usually useful for development and prototyping.

Generally, adding compute by switching to a larger Virtual Instance will make your queries faster. Typically, doubling CPU allocation (e.g., moving from Medium to Large will approximately double your query performance (e.g., reduce query latency from 100ms to 50ms). Note that eventually your queries will not be bound by compute and instead reach the limitations of the underlying infrastructure — at which point adding additional compute will cease to affect latency.

Generally, yes. For example, if you're running 50 queries-per-sec and add an additional 50 queries-per-second (for 100 queries-per-second total), each query will get a proportionally smaller compute allocation, and query latency will increase accordingly (generally proportional to the increase in QPS). In this example, you might notice a query latency increase of approximately 2x. If you want your query latencies to remain the same even when you double your QPS, you should migrate to a Virtual Instance that is 2x larger in size.

Alternatively, you can choose to create additional Query Virtual Instances, mount the required collections, and spread the query request load among those Query VIs. You can suspend and resume those VIs based on when the load is higher or lower.

We always recommend stress-testing production workloads before launching your application on Rockset.

Yes, a Virtual Instance has a fixed amount of compute resources. You can change the size of a Virtual Instance through Set Virtual Instance API endpoint.

You can have as many additional (Query) VIs as you need. Each Query VI adds a minor CPU overhead to the Ingest VI (responsible for stream ingest processing) and that overhead is dependent on the write rate of your collections. The lower the write rate on your collections, the lesser the overhead on the Ingest VI. This means that the size of the Ingest VI and your write rate determines the maximum number of Query VIs. Because Rockset is cloud-native, you can always increase the size of the Ingest VI if you want to increase the number of Query VIs.

You can resize your Virtual Instance at any time in the Virtual Instance tab of the Rockset Console. There is no downtime associated with this action. Once the resize is completed, Rockset will automatically begin executing queries on your new Virtual Instance.

Yes, the same collection can be mounted on more than one Virtual Instances. Writes to that collection are processed by the Ingest Virtual Instance. The other VIs are used to serve queries on that collection.

Yes, you can mount multiple collections on the same Virtual Instance.

The SELECT part of the query uses the compute resources from the Virtual Instance that is specified as part of the query request. This compute is used to generate the result set as specified by the SELECT query. Then the result set has to be inserted into the specified target collection. The compute resources from the Default Query Virtual Instance is used to write the result set into the target collection. You can find more information on the Default Query VI in our documentation here.