We’re excited to share that Cube has officially achieved Snowflake Ready Technology Validation, a recognition that underscores the strength of our integration with Snowflake and our shared vision for a more performant, consistent, and scalable data analytics ecosystem.

This milestone highlights not just a technical achievement, but a deepened commitment to all of teams that rely on Cube and Snowflake to power mission-critical data experiences—from BI dashboards to AI-powered applications.

## A Seamless, Certified Experience on Snowflake
The Snowflake Ready Technology Validation is a rigorous third-party assessment of integration performance, functionality, and best practices. Cube has met and exceeded Snowflake’s benchmarks for reliability, security, and performance—meaning our platform is officially certified to help you get the most out of your Snowflake investment.

This validation sits alongside our Premier Tier status in the Snowflake Partner Network, placing Cube among a select group of technology providers recognized for their impact, innovation, and success in helping customers accelerate data outcomes.

“Data analytics is the lifeblood of any company,” said Kieran Kennedy, Global Head, Data Cloud Products at Snowflake. “Cube’s Technology Ready status reflects the company’s commitment to enhancing performance, increasing reliability, and deriving more value for joint customers.”

## Built for the Modern Data Stack—and What Comes Next
Cube’s universal semantic layer integrates natively with Snowflake to support today’s full spectrum of data use cases: Modern OLAP, embedded analytics, enterprise BI, and AI-powered workflows. Whether you’re building trusted dashboards in Tableau and Power BI, operationalizing metrics in embedded data applications, or connecting governed data directly to an LLM, Cube acts as a translation and acceleration layer between the Snowflake Data Cloud and any downstream tool.

In our [deep dive on the Snowflake + Cube architecture](https://cube.dev/blog/how-cubes-universal-semantic-layer-and-snowflake-data-cloud-work-together), we walk through how Cube enhances performance by reducing data sprawl, unifying business logic, and optimizing query orchestration—especially important for organizations managing dozens of tools and users across teams.

And if you’re exploring [LLM-powered experiences with Snowflake](https://cube.dev/blog/bring-your-own-snowflake-llm), Cube can serve as the semantic layer that governs which metrics, models, and dimensions AI can access—ensuring both usability and security.

## What This Means for You
When you pair Cube and Snowflake, you get: 
- __Confidence__: Cube is validated by Snowflake to meet their highest technical and performance standards.
- __Velocity__: Our joint customers can move faster with fewer errors, more consistent data, and better alignment across teams.
- __Future-readiness__: Whether you’re scaling BI or prototyping AI agents, Cube and Snowflake together offer a future-proof foundation for your analytics stack.

This achievement is part of our ongoing commitment to helping data teams modernize and scale their analytics infrastructure with trust, performance, and flexibility at the core.

If you’re building on Snowflake and looking to unlock governed, AI- and BI-ready data at scale—Cube is ready when you are. [Contact sales](https://cube.dev/contact?utm_source=cube&utm_medium=blog&utm_content=snowflake-validation-blog) to learn more.


Brian Bickell

Snowflake

Accelerating the Future of Analytics with Snowflake

Cube Achieves Snowflake Ready Technology Validation

We're thrilled to announce a significant leap forward in our AI API capabilities, particularly for our valued users leveraging Snowflake. Last month, as part of the General Availability (GA) release of our powerful AI API, we proudly unveiled the "Bring Your Own Large Language Model" (BYOLLM) feature. This groundbreaking addition empowers organizations to seamlessly integrate their own compatible Large Language Models (LLMs) with our AI API, directly addressing critical concerns surrounding data security and cost optimization.

In today's data-driven landscape, organizations are increasingly seeking to leverage the immense potential of LLMs for various applications, from natural language processing to advanced analytics. However, with this increased adoption comes a heightened awareness of the need to protect sensitive data and manage costs effectively. This is where Cube's AI API with BYOLLM truly shines.

[Cube’s AI API](https://cube.dev/docs/product/apis-integrations/ai-api) allows Cube Cloud customers to use an LLM to interact with their data, via their trusted and governed universal semantic layer. Users can simply ask questions in natural language and the AI API will generate a Cube JSON Query to run or be run against our REST API, in order to answer their question. With BYOLLM an organization can choose to use a compatible LLM from their cloud provider and now from Snowflake the AI Data Cloud.

For organizations deeply invested in the robust Snowflake data cloud platform, maintaining LLM usage within the existing Snowflake security boundary and optimizing credit spend is of paramount importance. We recognize these priorities, which is why we're excited to highlight that you can now seamlessly utilize the cutting-edge Anthropic Claude 3.5+ Sonnet models offered on Snowflake Cortex directly with our AI API.

This powerful integration ensures that your highly sensitive data remains securely within your established Snowflake environment, where you have complete control over access and governance. At the same time, you can unlock the full potential of advanced AI capabilities, enabling you to derive deeper insights and drive innovation. Furthermore, this integration offers significant cost management benefits by consolidating your LLM usage within your existing Snowflake infrastructure and credit spend, eliminating the need for separate, potentially more expensive, AI services.

Getting started with this game-changing integration is remarkably straightforward. We've documented the process in our documentation, which you can access here. In essence, it simply involves enabling the BYOLLM feature on the AI API configuration page within Cube Cloud and securely saving your Snowflake Cortex credentials. This streamlined setup allows you to quickly and easily harness the power of Snowflake Cortex hosted LLMs with your Cube-powered applications.

We are acutely aware that a large and growing number of organizations are actively using open-source Cube or our fully managed Cube Cloud platform in conjunction with Snowflake. We deeply value this vibrant community and are particularly enthusiastic about collaborating with these organizations to facilitate their seamless adoption of the AI API using Snowflake Cortex hosted LLMs. We understand that each organization has unique needs and workflows, and we're committed to providing tailored support and guidance to ensure a smooth and successful integration.

We believe that the combination of Cube's AI API, BYOLLM, and Snowflake Cortex offers a powerful solution for organizations seeking to enhance their data security, optimize costs, and unlock the transformative potential of AI. By keeping your LLM usage within your Snowflake environment, you can maintain control over your data while leveraging cutting-edge AI models.

If you're interested in exploring this integration further and discovering how it can benefit your organization, please don't hesitate to reach out to us. Our team is readily available to answer your questions, provide technical guidance, and assist you in getting started. We are committed to helping you maximize the value of your Snowflake investment and unlock new possibilities with AI.

We're excited to embark on this journey with you and witness the innovative applications you'll build with Cube's AI API and Snowflake Cortex hosted LLMs. Let's work together to drive innovation, enhance security, and achieve new levels of efficiency. We look forward to hearing from you!

David Jayatillake

Artificial Intelligence

Bring your own Snowflake LLM 

Organizations today are grappling with growing data volumes, diverse sources, and increasing complexity in their analytics needs. While [Snowflake Data Cloud](https://www.snowflake.com/ "Visit snowflake.com") offers a highly scalable and powerful solution for managing and analyzing data, the challenge lies in ensuring that this data is consistently defined, easily accessible, and governed across the entire organization. This is where Cube’s universal semantic layer shines.

Snowflake Data Cloud is a fully-managed platform that provides elastic scaling, multi-cloud support, and a unified storage solution for structured and semi-structured data. It powers everything from data warehousing to real-time analytics, offering robust governance and security. However, transforming raw data into usable, consistent insights across the business requires an additional layer that simplifies how data is accessed, queried, and interpreted.

Cube provides one place to define business metrics, dimensions, and KPIs in a consistent way, ensuring data is interpreted uniformly across various teams, tools, and reports. It abstracts the complexity of Snowflake’s raw data and streamlines analytics for non-technical users, offering faster insights and more accurate decision-making.

## A Perfect Pair: Combining the Power of Snowflake Data Cloud with Cube’s Universal Semantic Layer
### Unify Your Data Architecture, Data Models, and Metrics
Snowflake Data Cloud allows businesses to store and manage vast amounts of data from multiple sources. But accessing this data in a consistent, meaningful way across the entire organization can be complex, especially when multiple teams and tools are involved. By integrating Cube with Snowflake, companies create a centralized semantic layer where business definitions, metrics, and KPIs are standardized. This ensures that every department—whether it’s finance, sales, or marketing—is working from the same trusted data definitions, regardless of the analytics tool they use.

### Improve Collaboration between Data and Business Teams
Snowflake’s infrastructure enables data engineering teams to efficiently manage data pipelines, ensuring that data is properly transformed and stored. However, there’s often a disconnect when business teams attempt to leverage this data for reporting and insights. Cube bridges the gap between technical and business users by providing a business-friendly interface to the data stored in Snowflake. Business analysts can self-serve their analytics needs through BI platforms, such as Tableau, Looker, and Power BI, and spreadsheets, such as Microsoft Excel, while Cube ensures that all calculations and metrics are accurate, governed, and consistent across the board. Connections are made via Cube's [native APIs](https://cube.dev/docs/product/apis-integrations), eliminating the need for direct database connections or data movement.

![](https://ucarecdn.com/1bf93e87-aa87-4715-8aee-4abbcfb48af3/-/quality/smart/-/format/auto/)

### Gain Real-Time Insights at Scale
Snowflake is known for its scalable, high-performance capabilities, allowing companies to analyze data quickly and at scale. But speed and scalability are only part of the equation—consistent and meaningful data is what drives actionable insights. Cube complements Snowflake by delivering real-time metrics at scale, enabling organizations to tap into their Snowflake data instantly with the confidence that they’re seeing reliable, consistent results. Together, they empower decision-makers to access the most up-to-date insights across any tool or dashboard, ensuring data-driven decisions are made in real time.

### Achieve Faster Time to Insight and Lower Costs
The combination of Snowflake’s elastic architecture and Cube’s optimization features helps organizations reduce the time spent on data preparation and improve query performance. Cube’s caching and pre-aggregation capabilities ensure that commonly used queries are accelerated, reducing the computational load on Snowflake. This not only speeds up time to insight but also optimizes infrastructure costs, allowing companies to fully leverage Snowflake’s capabilities without overburdening their budgets.

### Establish Governance and Compliance Without Compromise
As businesses grow, the need for strong data governance and security becomes paramount. Snowflake provides a secure foundation for managing data, with built-in features like encryption, role-based access control, and auditing. However, maintaining governance and consistency in how data is used across multiple teams and tools is critical. Cube ensures that governance policies are consistently applied across all downstream tools, eliminating the risk of metric discrepancies or data misuse. This level of control allows organizations to meet industry regulations, such as GDPR and HIPAA, without compromising on data accessibility.

## Together, Driving the Future of Data Analytics
By integrating Cube’s universal semantic layer with Snowflake Data Cloud, organizations can fully unlock the value of their data. Snowflake provides the infrastructure for storing, processing, and analyzing massive datasets, while Cube ensures that data is consistently defined and easily accessible for everyone in the organization.

This powerful combination helps teams:
- Break down data silos, democratizing access to critical insights across the entire business.
- Accelerate time to value by simplifying the process of preparing, serving, and analyzing data.
- Ensure governance, security, and compliance, from ingestion to insight, across all data platforms and tools.

Whether you're generating real-time dashboards, building machine learning models, or enabling self-service analytics, the combination of Snowflake and Cube provides a reliable, scalable, and consistent data foundation for all your needs. Contact sales to learn more about how Cube and Snowflake work together.

Michael Hetrick

How Cube’s Universal Semantic Layer & Snowflake Data Cloud Work Together

## Utilize the power and scalability of Snowflake.

We’ve long seen that the data experiences landscape has been very diverse. From dozens of general-purpose BIs to hundreds of vertical purpose-built analytical solutions, data consumers have many, many options to visualize and consume data.

The evolution of front-end technologies made it possible to embed quality analytics experiences directly into many software products, further accelerating the proliferation of data products and experiences. 

Cube works on top of Snowflake with direct queries and doesn’t require you to run extracts hence your data always remains in Snowflake. 

## What is a Semantic Layer?

A semantic layer is a middleware between your cloud data warehouse, such as Snowflake, and downstream applications. It abstracts raw data and presents it in a meaningful way to the end-user and serves as a contextual filter between the data warehouse and the various analytical tools that businesses use to slice, dice, and analyze their data.

![](https://ucarecdn.com/8d945f29-e9eb-4e7f-9e9e-29ae7074e195/)

## Why Cube and Snowflake?

**Future-proof data stack**. Snowflake established itself as the center of gravity in a **modern data stack**, a new approach to data engineering that enables teams to pursue higher-value activities. 

**Modern data stack** follows several foundational principles and architecture designs: 
* Using a cloud data warehouse like Snowflake as a central data platform
* [ELT vs. ETL](https://www.snowflake.com/guides/etl-vs-elt)
* Applying software engineering best practices to data management 

Cube embraces software engineering best practices and allows data engineers to [manage data model in code](https://cube.dev/docs/product/getting-started/cloud/create-data-model). This enables leveraging the version control systems to manage data model evolution safely and facilitate collaboration and code reviews. It also makes it possible to have a semantic layer as a part of the CI/CD process and have isolated environments for development, staging, and production.

**Utilize the power and scalability of Snowflake**. Cube works on top of Snowflake with direct queries and doesn’t require you to run extracts hence your data always remains in Snowflake. Cube pushes compute down to your Snowflake instance, fully utilizing the power and scalability of your cloud data warehouse. You can optionally create [pre-aggregations](https://cube.dev/docs/product/caching/getting-started-pre-aggregations) in Cube and enable aggregate awareness to not query your Snowflake instance with small repeated queries but rather update aggregates in the background.

## A step-by-step guide to building semantic layer with Cube and Snowflake

In the below section, we’ll cover a quickstart step-by-step tutorial on how to start with Cube and Snowflake. Cube Cloud is free to start, and you can sign up anytime. No credit card or calls with salespeople are required!

You can find a detailed getting started guide in Cube documentation. 

### Create Snowflake and Cube accounts
First, create Cube Cloud and Snowflake accounts.

If you don’t have a dataset that you would like to use, you can follow [this guide](https://cube.dev/docs/product/getting-started/cloud/load-data) to create a test dataset in your Snowflake instance.

### Connect Snowflake to Cube

Please follow these steps to create your first deployment in Cube Cloud and connect it to your Snowflake instance.

1. After you [sign in to your Cube Cloud account](https://cubecloud.dev/auth), click “Create Deployment”.

2. Give the deployment a name, select the cloud provider and region of your choice, and click “Next”.

3. Next, click Create to create a new project from scratch.
4. Select Snowflake from the list of supported data sources and enter your Snowflake credentials to connect to it. 
5. Once Snowflake is connected, Cube can generate a basic data model from your data warehouse schema, which helps you get started with data modeling faster. We'll inspect these generated files in the next section and start changing them.

### Create your data model
Cube follows a dataset-oriented data modeling approach, which is inspired by and expands upon dimensional modeling. 

When building a [data mode](https://cube.dev/docs/product/getting-started/cloud/create-data-model) in Cube, you work with two dataset-centric objects: cubes and views. Cubes usually represent business entities such as customers, line items, and orders. In cubes, you define all the calculations within the measures and dimensions of these entities. 

To begin building your data model, click on “Enter Development Mode” in Cube Cloud. This will take you to your personal developer space.

Once you are in developer mode, navigate to the “Data Model” and click on any file located in the left sidebar to open it.

You can follow [this detailed guide](https://cube.dev/docs/product/getting-started/cloud/create-data-model) on how to make changes to your data model and build new measures and dimensions.

When you are ready to test updates to your data model, you can navigate to [Cube’s Playground](https://cube.dev/docs/product/workspace/playground). The Playground is a web-based tool that allows you to query your data without connecting any tools or writing any code.

### Query your data
You can query Cube using a BI or visualization tool through the Cube SQL API. For a better experience, we recommend mapping the BI's data model to Cube's semantic layer. This can be done automatically with Semantic Layer Sync or manually.

**Semantic Layer Sync**
[Semantic Layer Sync](https://cube.dev/docs/product/getting-started/cloud/query-from-bi#semantic-layer-sync) will synchronize all public cubes and views with connected BI tools.
1. Create a new sync by navigating to the “Semantic Layer Sync” tab on the “BI Integrations” page and clicking “+ Create Sync”. 
2. Follow the steps in the wizard to create a sync
3. Replace the fields for user, password, and URL with your BI tool credentials, then click on “Save All”. You can now go to the “BI Integrations” page and trigger the synchronization of your newly created semantic layer.
4. After running the sync, navigate to your BI tool instance. You should see the orders_view dataset that was created in the tool. Cube automatically maps all metrics and dimensions in the BI tool to measures and dimensions in the Cube data model.

**Manual setup**
Alternatively, you can connect to Cube and create all the mappings manually. 
1. You can find the credentials to connect to Cube on the “BI Integrations” page under the “SQL API Connection” tab.
2. After connecting, create a new dataset in the BI tool and select "orders_view" as a table.
3. Now you can map the BI tool metrics and columns to Cube's measures and dimensions.

That was a high level preview. You can create both you Snowflake and Cube instance for free to try it out in your own environment.

### ...and you are ready to go...

The combination of Cube and Snowflake help to untangle the complexities of data modeling and empowers organizations to streamline their analytics efforts. Through step-by-step guidance, the blog has illuminated the path to creating a powerful semantic layer, enabling users to harness the true potential of their data and drive insightful decision-making. 

### More resources

Recorded workshop [Getting Started with Cube on Snowflake](https://cube.dev/events/unlock-data-cube-snowflake)

Detail on [connecting to Snowflake](https://cube.dev/docs/product/configuration/data-sources/snowflake)


Artyom Keydunov

Deep Dives

Getting Started with a Snowflake Semantic Layer 

About 6 months ago, we witnessed what Andy Pavlo [wittily characterised](https://twitter.com/andy_pavlo/status/1459251061085118465) as an "old school database benchmark gang war". The timeline of events goes like this:

* [Databricks](https://databricks.com), a data lakehouse company founded by the creators of Apache Spark, published a [blog post](https://databricks.com/blog/2021/11/02/databricks-sets-official-data-warehousing-performance-record.html) claiming that it set a new data warehousing performance record in 100 TB [TPC-DS benchmark](https://www.tpc.org/tpcds/). It was also mentioned that Databricks was 2.7x faster and 12x better in terms of price performance compared to Snowflake.
* [Snowflake](https://snowflake.com), a data warehousing company founded by ex-Oracle and ex-VectorWise experts, responded with a [blog post](https://www.snowflake.com/blog/industry-benchmarks-and-competing-with-integrity/) that critically reviewed Databricks' findings, reported different results for the same benchmark, and claimed comparable price/performance to Databricks.
* After two days, Databricks followed up with another [blog post](https://databricks.com/blog/2021/11/15/snowflake-claims-similar-price-performance-to-databricks-but-not-so-fast.html) that confirmed that they stand by the initially reported results.

While this back-and-forth between respected data vendors was informative and amusing, its collateral damage was even more substantial. Databricks shared that they have [eliminated the anti-competitive *DeWitt clause*](https://databricks.com/blog/2021/11/08/eliminating-the-dewitt-clause-for-database-benchmarking.html) from their service terms. Snowflake followed up with a [similar update](https://www.snowflake.com/blog/industry-benchmarks-and-competing-with-integrity/) to their acceptable use policy.

But what is the *DeWitt clause*?

More importantly, why would you need to know if a DeWitt clause is included in terms of service in case you'd like to do and publish a performance benchmark? Let's explore.

## Backstory of the DeWitt Clause

In 1982, at the very inception of relational databases, [David DeWitt](https://www.linkedin.com/in/david-dewitt-30189b50/), a researcher at the Department of Computer Sciences at the University of Wisconsin-Madison, was working on measuring database performance. His team wrote the Wisconsin Benchmark, tested a number of databases, and [published the results](https://pages.cs.wisc.edu/~dewitt/includes/benchmarking/vldb83.pdf).

Apparently, some folks were displeased with the results. [Michael Stonebraker](https://en.wikipedia.org/wiki/Michael_Stonebraker), a researcher at the UC Berkeley and co-creator of Ingres, called DeWitt and expressed how upset he was. However, they remained friends anyway as DeWitt recounts: in his [talk on YouTube](https://www.youtube.com/watch?v=-TIUGC4X2q8&t=420s):

<iframe width="800" height="500" src="https://www.youtube.com/embed/-TIUGC4X2q8?start=420" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

Oracle also didn’t perform very well and reacted hastily. [According to DeWitt](https://www.eweek.com/development/db-test-pioneer-makes-history/), Oracle CEO Larry Ellison was so displeased that he called the department chair and insisted, "You have to fire this guy.” Oracle also inserted a clause in their terms of use that boiled down to the fact that one can’t publish benchmarks without getting an explicit approval from Oracle.

## DeWitt Clause vs. DeWitt Embrace Clause

Nowadays, the DeWitt clause is a common provision in end-user license agreements for proprietary software that prevents from publishing information about the software without an explicit approval from the vendor. Over time, it have become widespread in the software industry and its implications are drastic:

* People avoid publishing benchmarks about software products with the DeWitt clause.
* Moreover, some won’t even bother doing a benchmark knowing they won’t be able to publish the results.

There are debates whether DeWitt clauses are [moral or legal](https://www.dwheeler.com/essays/dewitt-clause.html) because of the implications above as well as the overall corrosive effect they have on the industry. Once one supplier adds a DeWitt clause, the others can feel that they are at a disadvantage without one. We're lucky it can also work the other way round, like in the Databricks and Snowflake case. However, open source software (OSS) licenses don’t and can't have DeWitt clauses, meaning that the OSS can be legally critiqued, but not their proprietary competitors.

At the same time, some vendors do quite the opposite to the inclusion of a DeWitt clause. Instead, they change their license to the DeWitt Embrace Clause meaning that if you disclose benchmark results for them, you automatically allow them to do the same with you. In a way, DeWitt Embrace Clause is like copyleft for the DeWitt Clause. 

## Can You Benchmark %DATABASE%?

Now, do you wonder whether some vendor has or hasn't a DeWitt clause?

Shortly after the Databricks and Snowflake debate, [Mark Callaghan](https://twitter.com/MarkCallaghanDB), an ex-MongoDB and ex-Rockset database expert, checked if some database and public cloud vendors have DeWitt clauses in their terms of use.

In this blog post, I try to extend [his research](http://smalldatum.blogspot.com/2021/11/dewitt-clause-vs-public-cloud.html) and maintain an ever-green list of database and similar vendors with regard to the DeWitt clause. (If you spot any inaccuracy, which is totally possible, please get in touch via [igor@cube.dev](mailto:igor@cube.dev?subject=DeWitt), I'll be happy to update the post.)

*Last updated: June 2, 2022.*

### 😇 Open-source vendors (without the DeWitt clause)

Open source licenses usually grant users permission to [use open source software for any purpose](https://opensource.org/docs/osd). So, by definition, open source software can't contain DeWitt clauses (because if it did, it wouldn't be open source).

Yes, you can benchmark any of these tools:

* Apache [Drill](https://github.com/apache/drill), [Druid](https://github.com/apache/druid/), [Flink](https://github.com/apache/flink), [Hive](https://github.com/apache/hive), [Kafka](https://kafka.apache.org), [Spark](https://github.com/apache/spark)
* [appwrite](https://github.com/appwrite/appwrite)
* [ClickHouse](https://github.com/ClickHouse/ClickHouse) (they even maintain a [list of benchmarks](https://github.com/ClickHouse/ClickHouse/issues/22398) on GitHub)
* [CockroachDB](https://github.com/cockroachdb/cockroach) (licensed under BSL, not [OSI-approved](https://opensource.org/licenses/alphabetical))
* [Dremio](https://github.com/dremio/dremio-oss)
* [Elasticsearch](https://github.com/elastic/elasticsearch) (licensed under SSPL, not OSI-approved)
* [ksqlDB](https://ksqldb.io)
* [Materialize](https://github.com/MaterializeInc/materialize) (licensed under BSL, not OSI-approved)
* [MongoDB](https://github.com/mongodb/mongo) (licensed under SSPL, not OSI-approved)
* [PostgreSQL](https://www.postgresql.org)
* [Presto](https://github.com/prestodb/presto)
* [Redpanda](https://github.com/redpanda-data/redpanda) (licensed under BSL, not OSI-approved)
* [QuestDB](https://github.com/questdb/questdb)
* [TimescaleDB](https://github.com/timescale/timescaledb)
* [Trino](https://github.com/trinodb/trino)

Also, some open-source vendors collaboratively maintain benchmarking suites such as [Time Series Benchmark Suite](https://github.com/timescale/tsbs) to help choose the best tools for particular workloads.

### 😇 Vendors without the DeWitt clause

Cloud vendors can restrict you from benchmarking their services but sometimes they choose not to have the DeWitt clause.

Yes, you can benchmark any of these services:

* [Ahana Cloud](https://ahana.io/terms-of-service/)
* [Altinity Cloud](https://altinity.com/legal/)
* [appwrite Cloud](https://appwrite.io) (not launched to GA yet)
* [ClickHouse Cloud](https://clickhouse.com/cloud/) (not launched to GA yet)
* [Confluent Cloud](https://assets.confluent.io/m/103033bdcb9b3fcd/original/20220201-Confluent_Cloud_Services_Agreement.pdf)
* [Firebolt](https://d7umqicpi7263.cloudfront.net/eula/product/28a79f78-8008-4c02-a971-54ef6d8ed904/898eb1bc-7c2a-4829-b479-67f5a18a51ff.pdf)
* [Materialize Cloud](https://materialize.com/terms-and-conditions/)
* [MongoDB Cloud](https://www.mongodb.com/cloud-terms-and-conditions)
* [QuestDB Cloud](https://questdb.io/terms/) (not launched to GA yet)
* [Redpanda Cloud](https://redpanda.com/cloud/)
* [Snowflake](https://www.snowflake.com/legal/acceptable-use-policy/)
* [Starburst Galaxy](https://www.starburst.io/terms/galaxy-terms-of-service/)
* [Supabase](https://supabase.com/docs/company/terms)
* [Timescale Cloud](https://www.timescale.com/legal/timescale-cloud-terms-of-service)

However, many of these cloud vendors disallow *abusive benchmarking* in their acceptable use policies. So be careful and please don't get banned.

### 🙃 Vendors with the DeWitt Embrace clause

Some cloud vendors permit you to benchmark their service but require reciprocity: you must make the benchmark reproducible and allow benchmarking of your own service or tool in response.

Yes, you can benchmark any of these services and probably get away with it:

* [Amazon Web Services](https://aws.amazon.com/service-terms/), including [Athena](https://aws.amazon.com/athena/), [Aurora](https://aws.amazon.com/rds/aurora/), and [Redshift](https://aws.amazon.com/redshift/). *You may perform benchmarks or comparative tests or evaluations (each, a “Benchmark”) of the Services. If you perform or disclose, or direct or permit any third party to perform or disclose, any Benchmark of any of the Services, you (i) will include in any disclosure, and will disclose to us, all information necessary to replicate such Benchmark, and (ii) agree that we may perform and disclose the results of Benchmarks of your products or services, irrespective of any restrictions on Benchmarks in the terms governing your products or services.*
* [CockroachDB Serverless](https://www.cockroachlabs.com/acceptable-use-policy/). *You can only disclose benchmarking tests if you (i) provide us the necessary information to replicate the tests, (ii) disclose the methodology for the benchmarking tests along with the results, and (iii) allow us to run our own benchmarking tests against your products and services at our discretion.*
* [Databricks](https://databricks.com/blog/2021/11/08/eliminating-the-dewitt-clause-for-database-benchmarking.html). *You may perform benchmarks or comparative tests or evaluations (each, a “Benchmark”) of the Platform Services and may disclose the results of the Benchmark other than for Beta Services. If you perform or disclose, or direct or permit any third party to perform or disclose, any Benchmark of any of the Platform Services, you (i) will include in any disclosure, and will disclose to us, all information necessary to replicate such Benchmark, and (ii) agree that we may perform and disclose the results of Benchmarks of your products or services, irrespective of any restrictions on Benchmarks in the terms governing your products or services.*
* [SingleStore](https://www.singlestore.com/blog/eliminating-the-dewitt-clause-for-greater-transparency-in-benchmarking/). *Customer may perform industry standard benchmarks, comparative tests or evaluations (each, a "Performance Report") of the Managed Service. If Customer performs or discloses, or directs or permits any third party to perform or disclose, any Performance Report of any of the Managed Service, Customer (i) will include in any disclosure, and will disclose to SingleStore all information necessary to replicate such Performance Report and the data from the Performance Report, and (il) agree that SingleStore may perform and disclose the results of the Performance Report of Customer's products or services, irrespective of any restrictions on Performance Report.*

### 🤬 Vendors with the DeWitt clause

These vendors chose to restrict benchmarks with DeWitt clauses.

No, you can't benchmark any of these tools and get away with it:

* [Cloudera Data Platform](https://www.cloudera.com/legal/terms-and-conditions/cloudera-online-services-terms.html). *Restrictions. Customer may not: [...] access or use the Services for purposes of monitoring availability, performance or functionality of the Services, or for any benchmarking or competitive purposes.*
* [Decodable](https://www.decodable.co/legal/tos). *Restrictions. Customer may not, and may not cause or permit others to: [...] disclose results of any benchmark tests or performance tests of the Decodable services hereunder without Decodable’s prior written consent.*
* [Dremio Cloud](https://www.dremio.com/legal/terms-of-service/). *Restrictions. Customer shall not, and shall not cause or allow any Authorized User or third party to: [...] except with Dremio’s prior written permission, publish any performance or benchmark tests or analysis relating to Dremio Cloud.*
* [Elastic Cloud](https://www.elastic.co/agreements/global/cloud-services-monthly). *Restrictions [...] You shall not: [...] access or use any Cloud Service for purposes of monitoring its availability, performance or functionality, or for any other benchmarking or competitive purposes, including, without limitation, for the purpose of designing and/or developing any competitive services.*
* [Google Cloud Platform](https://cloud.google.com/terms/service-terms), including [BigQuery](https://cloud.google.com/bigquery) & [Firebase](https://firebase.google.com). *Benchmarking. Customer may conduct benchmark tests of the Services (each a "Test"). Customer may only publicly disclose the results of such Tests if it (a) obtains Google's prior written consent, (b) provides Google all necessary information to replicate the Tests, and (c) allows Google to conduct benchmark tests of Customer's publicly available products or services and publicly disclose the results of such tests. Notwithstanding the foregoing, Customer may not do either of the following on behalf of a hyperscale public cloud provider without Google's prior written consent: (i) conduct (directly or through a third party) any Test of the Services or (ii) disclose the results of any such Test.*
* [InfluxDB Cloud](https://www.influxdata.com/legal/terms-of-use/). *Restrictions. Customer will not: [...] publish or provide any benchmark, comparison or performance test results.*
* [MariaDB SkySQL](https://legal.mariadb.com/agreements/skysql/SkySQL_Terms_of_Service_V2_2020-12-16.pdf) and [MariaDB Xpand](https://legal.mariadb.com/agreements/xpand/xpand-license-terms-v2-2021-02-24.pdf). *Benchmarking. Customer may perform benchmarks or comparative tests or evaluations (each, a "Benchmark") of the SkySQL Services. However, Customer must obtain MariaDB's prior written approval to disclose to a third party the results of any Benchmark of the SkySQL Services.*
* [Microsoft SQL Server](https://www.microsoft.com/en-us/sql-server/). *BENCHMARK TESTING. You must obtain Microsoft’s prior written approval to disclose to a third party the results of any benchmark test of the software.*
* [Oracle](https://www.oracle.com/us/corporate/contracts/lic-online-toma-ph-de-eng-2817945.pdf). *RESTRICTIONS. [...] You may not: [...] disclose results of any Program benchmark tests without Oracle's prior written consent.*
* [PlanetScale](https://planetscale.com/legal/aup). *Customer will not, and will ensure that its End Users do not: [...] access any portion of the Product for the purpose of building a similar or competitive product or service, or monitor the Product for any benchmarking or competitive purpose.*

### 😶 Vendors for which the author didn't find the data

I wasn't able to identify where a few vendors stand with regard to the DeWitt clause:

* [MySQL HeatWave](https://www.mysql.com/cloud/)
* [Yellowbrick Data](https://www.yellowbrick.com/)

If you can provide any pointers, please get in touch via [igor@cube.dev](mailto:igor@cube.dev?subject=DeWitt), I'll be happy to update the post. Also, please reach out if you'd like more databases to be featured here.

## What about Cube?

[Cube](https://cube.dev) is an open-source [headless BI](https://cube.dev/blog/headless-bi) platform that [integrates with a lot of data sources](https://cube.dev/docs/config/databases): cloud data warehouses, query engines, and databases. Many of them are designed for low latency and some of them can provide high concurrency. However, sometimes they don't; you can read our [blog post](https://cube.dev/blog/data-warehouse-performance-and-how-cube-can-help) about that.

In any case, Cube will have no problem delivering your data, with sub-second latency and high concurrency, to any [data consumer](https://cube.dev/docs/config/downstream) out there: BI tools, data notebooks, front-end apps, etc. Thanks to [Cube Store](https://cube.dev/blog/introducing-cubestore), Cube's REST, GraphQL, and SQL APIs are able to respond to any request within 200-300 milliseconds and allow for 100+ concurrent requests—and that can scale.

Please explore how Cube integrates with [databases and other tools](https://cube.dev/blog/category/data) in the data space in our blog. Also, don't hesitate to try [Cube Cloud](https://cubecloud.dev/auth/signup), join our large [Slack community](http://slack.cube.dev), and give Cube a [star on GitHub](https://github.com/cube-js/cube.js) 🌟

Igor Lukanin

Performance

All database vendors who will either praise or punish you for doing a benchmark as well as an entertaining digression into the recent history of computer science

DeWitt clause, or Can you benchmark a database and get away with it

Adnan Rahic

Cloud Data Warehouses (CDW)

Performance capabilities of data warehouses and how Cube can help

Core to our business at [Simon Data](https://www.simondata.com/) is a data platform that enables our clients to access, operationalize, and centralize their marketing data.  The ultimate goal of Simon Data is to give marketers an intuitive, non-technical platform in which to manage sophisticated data operations required to drive great customer marketing outcomes.

![Simon Data Screenshot](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/a4a475ea-dcc6-4fea-8386-6ae3843c8ed8.png)

The warehouse is powered by a complex, multi-tenant environment comprising datasets of varying lineages, schemas, and business purposes. Some datasets are common across client accounts — such as data we produce or import through marketing channel integrations — while other datasets are client-specific. While this delivers significant leverage for our customers to orchestrate bespoke end-user impressions, it also introduces a brain-bending taxonomical challenge to the engineers looking to drive analytical insights across the entire system.

Since the product’s creation, the platform has seen several analytics products built into it. Early last year, we organized a focused team to consolidate them on a standard foundation. At that same time, we also wanted to rethink how we integrated analytics in our application to streamline the development and deployment processes.

We knew the best path forward was to build a framework that could be used both now and in the future for analytics product development on any part of our core platform. To pull this off, we had some goals for the system.

We wanted a seamless development experience, support for querying arbitrary data, fluency in managing various schemas, and an ability to rapidly prototype and develop the user experience. Equally important was the ability to transparently present the queries and transformations used to produce results to facilitate QA by multiple stakeholders.

## What our users wanted

When we talked with users and business stakeholders, we discovered several pain points:

- Users complained about difficulty configuring custom reports and limited dashboarding capabilities.
- Developers spent too much time maintaining multiple different and complex implementations of analytics products.
- Salespeople wanted an easy-to-use and effective out-of-the-box reporting dashboard to present to prospective clients.
- Client Solutions Managers wanted more transparency in how the system calculated results.
- Product managers and engineers were concerned about the level of effort required to build new analytics products.

## Enter Cube.js

We started with a holistic review of the analytics products we already had to gather requirements for the new reporting suite and took a close look at how clients were (or were not) using them. Alongside that, we also did a systematic review of technologies we could use to build a new reporting platform.

We looked at many commercial products and open-source projects and narrowed the list down to a handful of contenders, including [Apache Kylin](http://kylin.apache.org/) and Druid from the open-source space and Looker from the enterprise. Cube.js quickly rose to the top of that list.

What we liked most about Cube.js (no other offering provided all of these):

- It was designed for precisely the problem we were trying to solve, which was embedding analytics into an existing application, and it fits nicely into our existing technology stack.
- First-class support for the tools we use: Snowflake on the backend and React/Recharts on the frontend.
- Pluggable authentication and schema configuration hooks we could use to integrate with the rest of our platform. Specifically, we use [driverFactory](https://cube.dev/docs/config#options-reference-driver-factory) to provide credentials for Snowflake and MySQL (for external pre-aggregations).
- Out-of-the-box support for deploying as a serverless application on AWS Lambda with API Gateway, ElastiCache, and Aurora/MySQL.
- A fantastic developer sandbox app, [Developer Playground](https://cube.dev/docs/dev-tools/dev-playground), which provides interactive query development, troubleshooting/debugging, the export of queries, and even ready-made Recharts components.
- [Multiple layers of caching](https://cube.dev/docs/caching) to provide the performance necessary for interactive data visualization in our application.
- An integrated framework for building frontend data components leveraging our massive data warehouse, one that was lightweight and enabled rapid iteration without a lot of boilerplate, nor the need to wire together lots of different libraries.

## Where we had to invest in Cube.js

Marketers interact with Simon Data through our easy-to-use web application. We needed a way to query data from multiple independent data warehouses, each with its different schema, and present the results in a common interface. This was a challenge on two fronts: development and deployment.

First, we had to invest in integrating Cube.js with our infrastructure to provide credentials and schema configuration for each individual client's data warehouse. Cube.js provided hooks we could use, so this was reasonably straightforward.

However, we needed to give developers a way to run Cube.js to mirror the production environment while being able to rapidly iterate on schema, query, and frontend component development. This meant building a common application bootstrap and configuration for Cube.js that we could use to launch it in dev, staging, and production environments.

One neat trick we pulled off here was getting Cube.js to seamlessly serve both its playground application and API queries from our web app when running in development mode. This is important for us to be able to run everything (i.e. both Cube.js and Simon Data web app) on our laptops and have the web app be able to send queries to the Cube.js Playground running locally.

Another challenge we faced was safely and securely deploying configurations to production without impacting what was already running. We achieved this by making schemas immutable.

When we want to deploy a new schema or patch an existing one, we create a whole new schema or increment the current schema with the changes. Once we have the latest schema working in our development environment, we can test it out in the staging environment and deploy it to production. We can do all of this in the background, so we only switch the production web application over to the new schema once we have complete confidence in it (see Figures 2 & 3 below).

Our repeatable deploy process sets up the new schema in Snowflake and Cube.js simultaneously, which gives strong consistency between the Snowflake and Cube.js configurations.

We have defined schemas as a set of Snowflake views and Cube.js cubes that are developed and deployed together. We create a schema by writing view templates that map onto the data in Simon’s warehouse designed for the given customer to provide a standard interface to create the cubes on top of (see Figure 1 below). Our developers write these view and cube templates using [Jinja](https://palletsprojects.com/p/jinja/) from their IDEs and can rapidly iterate on them locally using our end-to-end development environment integration. Once the schema is complete and committed, our deployer tool dynamically renders the templates by filling in variables specific to each customer’s datasets. This pattern was the key to building repeatable schemas and deploying them consistently in our complex multi-tenant environment.

Finally, we created a comprehensive, automated end-to-end integration test suite (written in Python) that exercises each cube across all schemas that are live in Cube.js. This serves two important purposes:

1. It validates our production environment.
2. It keeps the Cube.js pre-aggregations database up to date ahead of user interaction.

The integration test runs periodically and also after the deployment of any new schemas. Once the test passes, we can safely switch the web application to the new schema with confidence.

### How Cube.js is deployed at Simon Data

![Figire 1](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/329b1deb-0db8-4c31-a91a-8aa93d4c817c.png)
**Figure 1: Schema is the unit of deployment**

- Each schema gets deployed into both Cube.js and Snowflake at the same time.
- A schema is composed of one or more sources. Each source defines a particular data source.
- Sources are where developers work. During development, the Cube, View, and Table definitions are created as a single unit (a source) that powers one or more in-app features.
- In a source, each Cube (Cube.js config files) has a dependent View (with a SQL query, which the Cube is defined on top of), and each View has one or more dependent Tables (with a name and list of columns that are verified in validation).
- Tables represent the upstream data in the data warehouse that we want to bring into the web application with an in-app reporting feature.

![Figure 2](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/fc652e61-0640-463f-b8ed-0b7d0375b12d.png)
**Figure 2: Deployment process**

- Create a new schema in the Cube.js Playground.
- Deploy the schema into Snowflake & Cube.js.
- Switch the Simon Web App to use the new schema.

![Figure 3](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/3d5dc184-927a-4216-9bef-345227ed7b99.png)
**Figure 3: Schema migration**

We can develop a new schema and deploy it in the background, then switch the Simon web app over when ready.

## How are we better of now?

We delivered three major wins to our clients and business stakeholders with this platform:

**Speed.** We can develop and ship analytics products without dealing with any net new infrastructure development going forward. Our efforts are focused on what matters: the data and the UI. Integrating the Cube.js Playground into our development stack enables us to rapidly build a schema and query in Cube.js and then export that for implementation in the front end, all of which a developer can quickly do on a laptop.

**Flexibility.** We have a framework that enables us to seamlessly query any data in Snowflake and present it in the web application. The real win here is that we won't have to choose between maintainability and time to market to get this flexibility -- we can have both.

**Stability (Antifragility).** When we're ready to ship a new product feature, we can deploy it with the confidence that we will not introduce regression on existing functionality because our schemas are immutable. We can also roll out new features to client accounts in a controlled manner, one by one or in batches, and even keep the changes hidden to perform production validation before they are released to end users.

## Results and future plans

We’ve already built net-new analytics products on this platform that solve fundamental client pain points, proving that the platform works. We’re also starting to realize the velocity gains when iterating on these products to add functionality and refine the user experience.

Now we’re starting to look at consolidating some of the earlier analytics products onto the new framework. Finally, our business stakeholders now have transparency into the calculations that power analytics products in the application, giving them confidence in the data and helping them more easily answer client questions.

## Interested in joining Simon Data's success with Cube.js?

Explore Cube.js [examples & tutorials](https://cube.dev/docs/examples) and [get started](https://cube.dev/docs/getting-started) today. To jumpstart your efforts, please join us on [Discourse](https://forum.cube.dev/) & [Slack](https://slack.cube.dev/), follow us on [Twitter](https://twitter.com/thecubejs), and get engaged with the growing Cube.js community.