Sizing Guidelines

To maximize the operational efficiency of Zoomdata, you need to take into account several factors to appropriately size the Zoomdata Server in your operating environment:

  • Number of concurrent users during peak access times

  • Size and number of the data sources you want to connect to

To better understand how to size your server for optimum performance, review the following information. If you have unique sizing needs for your environment, contact Zoomdata Technical Support for more information.

See also System Requirements for information about Zoomdata system requirements.

Sizing Profile

Profile Description

Demo, Proof of Concept (POC) The most basic profile, supporting 1-2 concurrent users.
10s of Users For the smaller organization that will have less than 100 users at any given time.
100s to 1000s of Users

For the mid-size to large organizations that will have 100 or more users at any given time.

Contact Zoomdata Technical Support to get help in setting up Zoomdata in your operating environment in the best configuration possible.

Server Sizing

Sizing the server requires using a performance profile based on the expected number of concurrent users. Also keep in mind the size and number of data sources being accessed by Zoomdata impacts the sizing profile. Scale-out and load balancing may also be needed, depending on your organization’s operating environment.

Adjust your hardware to account for both an increasing number of users and size of the data source:

  • CPU: number of cores
  • Memory allocated to Zoomdata
  • Disk space that may be used by Zoomdata

The following table reviews the recommended sizing guidelines for your server. Keep in mind that the specifications provided are suggested starting points and reflect only the minimum estimates. Sizing Zoomdata for performance is impacted by many other factors outside of the ones mentioned here, such as where Zoomdata resides, the types of data sources you are using, interactions between applications and data sources, and a variety of other factors.

Concurrent users represent only a portion of the total number of available users in an organization who may access the Zoomdata server at the same time. In general, Zoomdata estimates that 20% of the total user base will be logged onto Zoomdata at any given time. So if an organization has 1000 total users that have access rights to Zoomdata, we estimate that 200 users may be logged concurrently.

A single Zoomdata server has been tested for up to 100 concurrent users at any given time. When testing user concurrency, factors including the cardinality of the data sources, loading, sharpening, and visualizing results in dashboards were considered.

Sizing Profile (For Concurrency) Size of the Data Source CPU: # of Cores (Minimum) Memory allocation JVM Memory allocation Disk space (Minimum) Supported # of concurrent users (Per server) Assumptions

Demo, POC, 1-2 users

Megabytes (MBs) of data


16 GB

8 GB


250 GB


Metadata store is embedded (on the same server as Zoomdata)

10s of concurrent users

Gigabytes (GBs) of data


64 GB

20 GB*

500 GB

<100 Metadata store is embedded (on the same server as Zoomdata)

100s to 1000s of concurrent users

Terabytes (TBs) to Petabytes (PBs) of data

Contact Zoomdata Technical Support 100+ Contact Zoomdata Technical Support

By default, the JVM memory setting is set to use a max of 8 GB. For 10s of concurrent users, the recommended allocation is 20 GB. For instructions to increase the JVM memory, read Configuring Zoomdata's Memory Settings.

Zoomdata Service Memory Allocation

Each service within Zoomdata has a default sizing configuration. To better understand how much memory each Zoomdata service uses so that you can judge your performance needs, review the following table. You can also use Zoomdata's memory allocation script to calibrate your environment. Doing so calculates the memory allocation for each service based on the total memory available on your server or a specified amount for memory allotment. For more information, see Zoomdata's memory adjuster on github.

Service Name What it does Required to run? Default memory
zoomdata Entry point and provides front-end configurations Yes JVM: 2GB
zoomdata-query-engine Holds all functionality related to visualization query processing Yes JVM: 6GB
zoomdata-scheduler Provides ability to schedule repeating actions inside Zoomdata platform Yes JVM: 1GB
zoomdata-edc-<connector>* Connects to specific data source Yes JVM: 250MB per connector
zoomdata-upload An API for receiving data requests and placing them on to the message queue for processing No Varies
zoomdata-streamwriter A receiver for messages to write data or perform operations on collections No Varies

* EDC memory allocation varies when the connector is not in use. Memory varies based on the number of concurrent requests and query results.