Production Readiness

Before productionalizing applications powered by Rockset, it's important to consider a range of crucial factors. We've created a comprehensive checklist that Rockset users can go through to ensure their setup and architecture aligns with Rockset's best practices for production workloads.


  • Separate development and production environments by using distinct Workspaces or different Rockset accounts (examples of how to do this here).
  • Utilize Terraform (and/or Rockset API) for deployment.


Data Management

Compute Resources

Query and API Access


Security and Access Control


High Availability/Disaster Recovery

  • Use single or multi-region deployment to achieve higher levels of availability, if applicable.
  • Use collection snapshots to keep a copy of data, if relevant.
  • Build an emergency query re-direct to a new VI in case the current VI becomes overwhelmed. Test by building an internal failover and timing how long it takes to switch 100% of queries to a new VI.


  • Know how to reach Rockset Support (via chat support and/or support tickets).
  • Enable Rockset Support Access by navigating to the Security tab of the Rockset Console.
  • Subscribe to the Rockset status page.
  • If you have a support contract, run a mock fire drill. File a SEV1 support ticket and time how quickly support acknowledges the ticket.

Billing and Cost Management


Rockset Asset Topology

Mental model on how different assets/components are organized within a Rockset organization:

Rockset Asset Hierarchy

Hierarchical representation of assets/components within Rockset:

Rockset Environment Separation

Separate environments (dev, test, production, etc.) by having multiple Rockset organizations (for example — one for dev/test, one for production) and using workspaces within them to separate use cases. This ensures complete separation of resources and is the recommended way of separating environments.

Separate environments by having a single Rockset organization with workspaces for each environment and use case (for example — dev/test for use case 1, prod for use case 1, dev/test for use case 2, prod for use case 2).