Frequently Asked Questions

How does SELECT differ from other products in the market?

SELECT is the leading cost management & optimization platform for Snowflake, adopted by over 200 companies. Our primary differentiation from other products in the market like Slingshot or Keebo comes from four main factors:

1. We are an end to end platform

In addition to having fully automated warehouse optimization capabilities which reduce compute costs by up to 20% like Keebo, we also provide comprehensive cost visiblity, surface additional optimizations teams can implement, flexible cost allocation capabilities, and a variety of out of the box alerts to help teams control costs long term.

2. Depth

Many Snowflake customers will have some home grown cost dashboards and alerts in place, which they eventually learn fall short of their needs due to a lack of depth. If you have a single BI tool warehouse costing hundreds of thousands of dollars per year, how can you identify which dashboards and business users are responsible for that consumption? What if you want to filter costs by object tag or identify which specific queries are driving the highest AI services spend? What is the cost of each Dynamic Table, SPROC, and Task.

Due to having to support over 200 customers, we get asked questions like this every day and have grown our product accordingly.

3. Integrations

A large majority of Snowflake consumption comes from 3rd party tools like dbt, Fivetran, Coalesce, Sigma, Looker, Tableau, and more. SELECT actively builds and maintains first party integrations for these tools so you can see the Snowflake costs they drive, along with their lineage.

4. World Class Product Support

We create a shared Slack/Teams channel with every SELECT customer, allowing us to give you a world class support experience. We respond to questions and feature requests within hours. We regularly hop on a calls with customers to help them implement a new Snowflake feature, refactor one of their queries, or help them implement advanced object tagging strategies to improve their cost allocation strategy.

Interactions like these go a long way and help you get additional value from working with us.

Why doesn't SELECT charge a % of savings?

Many of our customers ask us why we don't charge a % of savings as a cost management product.

First off, it becomes very complicated. Let's say we identify a compute process that costs $50/day loading a table that no one queries. Or maybe we identify a workload that has been failing for the past month, wasting $40/day.

After you action that insight and deprecate the workload, how much did we save you? $50/day for 6 months ($9K)? $50/day for 12 months ($18K)? This quickly becomes a game of what-if. How long would it have taken for you to notice this compute process and deprecate it yourself?

What about when we alert of you a job which has suddenly increased in costs then the developer goes and fixes the query the next day in response?

It gets messy.

There's an important quote from the world of FinOps which we strongly believe in:

The greatest cloud savings come from costs never born.

One of the biggest value adds of SELECT is we help you catch things before they become an issue. In addition, through ongoing usage of our product Snowflake users around a company become more educated on best practices and how different actions impact costs.

Our goal is to help you prevent spend issues or misconfigured warehouses from existing in the first place! We'd much prefer that then letting things run innefficiently for 6 months just so we can claim a % of the savings.

Why doesn't SELECT automatically resize warehouses?

Many customers ask us if we automatically change the size of a virtual warehouse throughout the day. While this sounds great in theory, it doesn't turn out that way in practice.

With many of our customers who have tried solutions which offer this, they've experienced both:

1. Performance issues as a workload suddenly loses over half of its available computing power / memory.
2. User confusion, as users who are expecting to run a query against a Large warehouse suddenly have a Small warehouse to work with.

Changing the warehouse size will always impact performance, unless your warehouse is grossly oversized and none of the queries running on it are properly utilizing the warehouse's available compute.

If that's the case, why not downsize the warehouse yourself versus pay a provider 25% of the cost savings from having their solution downsize it for you?

When it comes to warehouse sizing, we believe in providing customers with the tools & insights that tell them which specific workloads should be run on a different warehouse size, or if the warehouse as a whole should be downsized or upsized based on the workloads running on it.