Sign inTry Free

Important

Helios features are now enabled during weekly update windows and are no longer directly tied to SingleStore engine releases. Refer to the release notes to view the latest features available in your Helios cluster.

System Limits

On this page

This topic specifies maximum sizes and numbers of various SingleStore Helios components. Use the following links to navigate to a section below:

Cluster-Level Limits

Components

Limit

Maximum clusters in a group

5

Maximum number of clusters to which a database can be attached in R/W mode

1

Maximum cluster size

S-384 (vCPU: 3072; Memory: 24576 GB)

Refer to the pricing page for more details.

Number of databases per cluster

No fixed limit. Recommended limit: 20.

It depends on the size of each database. Databases are sized differently based on the number of partitions, amount of data, metadata and number of tables, etc.

Refer to SingleStore Helios Sizing Guidelines for more details.

Maximum number of concurrent queries

This varies according to the deployment size.

Maximum simultaneous client connections

This varies according to the deployment size.

Number of security users per aggregator

16,383

Database-Level Limits

Item

Max Spec (enforced)

Max Spec (recommended)

Comments

Number of tables in a database

Each table costs some per-table memory overhead.

Number of partitions in a cluster

None

Number of database partitions per node

2414

Table-Level Limits

Item

Max Spec (enforced)

Max Spec (recommended)

Comments

Number of columns per table

4096

Row size in bytes

64KB *

Limit does not apply to variable-length strings such as VARCHAR, VARBINARY, TEXT, etc.

Length of names in characters (applies to table names, column names)

256

Number of indexes per table

63

Number of columns per index

32

Number of tables in a join for each SELECT

253

Number of entries in a SELECT projection (target) list

12800

Number of nested sub-select queries using the UNION statement

337

40

Beyond 40 the UNION statements are converted to TABLE function.

Number of parameters per query

1,048,576

Configurable via parametrizer_query_max_params. Refer to List of Engine Variables for more information.

Function Arguments

Non-external functions and stored procedures: 256

External functions: 4,096

* The number of fields that will fit in the 64KB maximum row size is determined by the field types and how rows are laid out in the in-memory rowstore format. In some cases, writes (inserts and updates) to columnstore tables are implemented by storing the newly written rows in a rowstore format before flushing them to the column-oriented format. The row size limit applies to fixed-width data which includes a 4-byte nullability flag for nullable fields. The row size limit does not include the body of variable-width fields, but only the in-row portion, which includes an 8-byte memory location pointer and an optional 4-byte nullability flag. The sum of the in-row data size for all columns cannot exceed 64KB."

Naming Constraints

Item

Constraints

General

  • Name cannot be blank.

  • Name cannot end with a space.

Database names

  • Database names can only contain alphanumeric characters and underscores, and cannot start with a digit.

  • Maximum length of 64 characters.

Table names

  • Table names can contain both alphanumeric and non-alphanumeric characters, but cannot contain the / character.

  • Maximum length of 256 characters. **

Other database objects (stored procedures, views, user-defined functions, user-defined aggregate functions, and table-valued functions)

Maximum length of 256 characters. **

User names

  • Non-JWT users: Maximum length of 32 characters.

  • JWT users: Maximum length of 320 characters.

Role names

No length limit. Cannot contain commas or spaces.

Group names

No length limit. Cannot contain commas or spaces.

** Column aliases are truncated during projection (SELECT) to 256 bytes (not characters) which impacts names that use multi-byte characters. The full names are stored in the database and can be queried. Information schema tables can be used to view the full names.

Last modified:

Was this article helpful?

On this page

Was this article helpful?

Verification instructions

Note: You must install cosign to verify the authenticity of the SingleStore file.

Use the following steps to verify the authenticity of singlestoredb-server, singlestoredb-toolbox, singlestoredb-studio, and singlestore-client SingleStore files that have been downloaded.

You may perform the following steps on any computer that can run cosign, such as the main deployment host of the cluster.

  1. (Optional) Run the following command to view the associated signature files.

    curl undefined

  2. Download the signature file from the SingleStore release server.

    • Option 1: Click the Download Signature button next to the SingleStore file.

    • Option 2: Copy and paste the following URL into the address bar of your browser and save the signature file.

    • Option 3: Run the following command to download the signature file.

      curl -O undefined

  3. After the signature file has been downloaded, run the following command to verify the authenticity of the SingleStore file.

    echo -n undefined |
        cosign verify-blob --certificate-oidc-issuer https://oidc.eks.us-east-1.amazonaws.com/id/CCDCDBA1379A5596AB5B2E46DCA385BC \
          --certificate-identity https://kubernetes.io/namespaces/freya-production/serviceaccounts/job-worker \
          --bundle undefined \
          --new-bundle-format -
    Verified OK

Try Out This Notebook to See What’s Possible in SingleStore

Get access to other groundbreaking datasets and engage with our community for expert advice.

Sign UpLog In