Sign inTry Free

Shared Edition

On this page

SingleStore provides a free entry point to get started with SingleStore Helios for low-throughput and prototype applications. In the Shared Edition, users create a Shared cluster to use SingleStore Helios. A Shared cluster uses a shared compute environment and allows users to create a single database for their needs. To learn more about Shared Edition limitations, refer to Configuration Limits for Shared Clusters and Operational Limits for Shared Clusters.

Considerations:

  • Each Shared cluster is allowed to have only one database.

  • Shared clusters can only be deployed in AWS US-EAST-1 region. If you require a deployment in a specific region of AWS, or in a different cloud provider (GCP or Azure), spin up a regular cluster in SingleStore Standard or Enterprise edition.

  • Shared clusters are not intended for Production use. Use a Standard cluster for high-traffic, compute-intensive apps for production workloads. These clusters support read replicas, shared deployments, and have full access to all latest SingleStore features.

  • Shared clusters are not intended for Benchmarking. Use a Standard cluster to take full advantage of SingleStore's performance capabilities.

Configuration Limits for Shared Clusters

Configuration Option

Limit

Cloud Service Provider and Region

Shared clusters can only be deployed in AWS US-EAST-1 region.

SingleStore Versions and Upgrades

The underlying cluster is automatically upgraded once the latest version of SingleStore becomes available.

# of Shared Clusters

Unlimited.

Cluster Size

You cannot configure memory or vCPU size for Shared clusters.

Naming Databases

You must select a unique name for your database in a Shared cluster. There is a single global namespace for all databases on a Shared cluster.

Note

While database names have to be unique, your data is fully isolated from all other databases and organizations.

Naming Database Users

You must select a unique name for your database users in order for them to access a Shared cluster. There is a single global namespace for all database users.

Note

Only your database users have permissions to access your database in a Shared cluster.

Automated Backups

Not supported.

Moving to Standard and Enterprise Clusters

To move data, back up a database and then restore it to a Standard or Enterprise project.

Advanced Security and Routing

No support for Private Links, SSO, or CMEK.

Configuring Firewall Access

No support to configure where your database can be accessed from (it is accessible from anywhere by default).

Audit Logging

No support for audit logs.

SingleStore Stage

Supports SingleStore Stage up to 10 GB of storage.

Updating Global Variables

Users cannot change global configurations for their deployments.

Support for CREATE DATABASE and DROP DATABASE

These SQL commands are disabled for Shared clusters. To drop your database, you need to terminate the Shared cluster using the UI.

Operational Limits for Shared Clusters

Component

Limit

# of Shared Clusters per Org

Unlimited.

# of Databases per Shared Cluster

1

You cannot use DROP DATABASE command on the Shared cluster. To drop your database, you need to terminate the Shared cluster using the UI.

# of Tables per Database

10

# of Reference Tables

No reference tables.

# of Rowstore Tables

No rowstore tables.

# of Pipelines

10

Note

CDC-in pipelines are not supported in Shared Edition (Shared clusters). To ingest data using CDC, SingleStore recommends using SingleStore Flow or a Standard/Enterprise deployment instead.

# of Stored Procedures and User-Defined Functions

10

Data Size

1 GB of compressed data. SingleStore typically sees 75% compression on average, depending on the data set. Refer to SingleStore Helios Sizing Guidelines for more information.

# of Database Users

3 Users. Users can be admin or Read only.

# of Concurrent Incoming Connections

100

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