Watch the 7.3 Webinar On-Demand
This new release brings updates to Universal Storage, query optimization, and usability that you won’t want to miss.

Getting Started

We are excited for you to get started accelerating your BI dashboards by augmenting your cloud data warehouse with SingleStore Managed Service (SSMS). We have many users that have started their BI projects with data warehouses like Redshift, Snowflake and BigQuery, and realized that due to the need for fast ingest, performance, and high concurrency, they needed to augment their architecture with a highly performant, scalable cloud-native database.

Some terminology used in this guide:

  • App/Application: Web- or mobile-based, customer or internal facing application.
  • Dashboard: Visual analytics displayed either through commercial business intelligence tools or custom-built solutions.
  • Object storage: Cloud-based data repository.

Data warehouse users often find improved query latency and concurrency support using SingleStore Managed Service as the data store directly fueling their dashboards, while retaining their data warehouse for long term storage. Not only that, but data ingested directly into SingleStore is immediately able to be queried, rather than waiting minutes or hours for batch ingest into the data warehouse to complete.

Let’s get started by discussing some of the basic things to consider when bringing your data over from one of these data warehouses.

Things to Consider

For users starting with a database already hosted in a cloud provider like AWS, GCP, or Azure, you may already have your data sitting in object storage (if not, we walk through how to do this later). SingleStore has a feature called Pipelines, which allows you to bring in data from any of these places very quickly. We’ll go through how to do this in a bit.

Now, of course, every database is different. Let’s talk a bit about database design differences.

Things to know, regardless of your current platform:

  • SingleStore Managed Service can be deployed in any of the three major clouds, in any region – so you don’t have to worry about moving regions.
  • Cloud Enterprise Data Warehouses (EDWs) typically leverage ANSI SQL, and SingleStore does too. However, SingleStore leverages MySQL syntax so there may be some modifications required. SingleStore is also ACID compliant.

Things to know for specific databases:

Snowflake

  • Users often use SingleStore Managed Service in conjunction with Snowflake to achieve improve concurrency and ingest SLAs at a lower overall TCO.
  • Snowflake separates storage (S3) and compute (virtual warehouses). SingleStore Managed Service couples them which generally helps with predictability of cost. The future of S2MS will also bring features like separation of storage and compute to help with burst BI workloads.

Redshift

  • Users often use SingleStore Managed Service in conjunction with Redshift to improve overall query latency for workloads with transactions and analytics.
  • Many users come to SingleStore Managed Service after they have reached the Redshift column limitation as well.
  • Redshift’s “leader nodes” and “compute nodes” correspond to SingleStore Managed Service’s aggregator nodes and leaf nodes. Aggregators handle client communication and query orchestration, and leaf nodes manage data and compute power. You don’t need to know too much here given that this is a managed service, but you’ll see the node types denoted within the “Nodes” section of Portal.

BigQuery

  • Users typically find SingleStore Managed Service to be faster in overall ingest speeds and query latency with concurrency, but may find BigQuery simpler to implement with the overall GCP stack.
  • BigQuery separates storage (GCS) from compute (units). SingleStore Managed Service couples them which generally helps with predictability of cost. The future of S2MS will also bring features like separation of storage and compute to help with burst BI workloads.

Azure Synapse

  • Synapse’s “control nodes” and “compute nodes” correspond to SingleStore Managed Service’s “aggregator nodes” and “leaf nodes”. Aggregators handle client communication and query orchestration, and leaf nodes manage data and compute power. You don’t need to know too much here given that this is a managed service, but you’ll see the node types denoted within the “Nodes” section of Portal.