Where Does Slight Fit In?

When to use Slight, and When To Use Existing Tools

Slight intentionally doesn't try to do everything. This allows us to stay lightweight and focus on enabling data analysts to drive value. Here we'll discuss when Slight works better, and when existing tools and processes might be a better fit for the task.

Slight or Dashboards

Or more generally, business intelligence tools.

Dashboards get a lot of stick - cumbersome, unreliable, slow and heavy, hard to trust. Some of this is fair, but a lot of this criticism is because they're tasked with too much. They are a high level tool - they aren't nimble enough to handle emergent business questions that evolve almost daily.

They do have their uses: they are a high-level window into a company's data, and therefore a window into the company itself. But oftentimes, people need to do more than look.

Slight is unlikely to compete with Tableau's ability to create a beautiful code-free chart. But the same tool doesn't need to be the one delivering data to your ops team. This only gets worse when it comes to your frontend team: they're looking for a modern API to hit. They're not interested in the same tool generating beautiful PDF reports.

Slight is particularly useful when dashboards are not suitable for a desired analysis. When dashboards aren't the desired destination, Slight gives you a lightweight way of getting data to your ops team. We're there when you need an easy way to give your finance team data in a spreadsheet. And of course it's no extra work to generate an API for your developers.

When Dashboards and BI are More Appropriate

Dashboards can be a better fit when you need many complex graphs or many simultaneous views on the same page and are willing to wait for them to load. Even in these cases, you can build your dashboards on top of queries specified in Slight.

Slight doesn't yet have good support for "end-to-end" self service: that is, creating a query without code, using a visual or click-and-drag interface. Some BI tools do a nice job here.

Dashboards often are criticised for hiding the source query. We think your dashboarding tool doesn't need to be where your analysts also reshape the data. Building sophisticated queries within your BI tool adds friction when reusing that query elsewhere.

When Slight Is More Appropriate

When the Data Tool Isn't the Final Destination

Slight shines when the analysis is best done outside of the standard data tool stack, or when the data needs to be shipped somewhere else. BI tools and dashboards can easily become data black holes - Slight doesn't want to be your terminal node.

Writes, Updates, and Internal Tools

Slight is close to the code and data. This means your queries and scripts can easily insert into or update your databases through Slight. Slight can thus be a home for data-focussed internal tools - let customer service flag an account through a lightweight UI without involving engineering.

Turning Queries into APIs

When sharing data and metrics internally, you don't want to be forced to work within your data tools - especially if your internal teams are comfortable with APIs. Further, you can share data on your homepage or with your clients too - an emailed CSV doesn't always cut it.

Adding Datasets to the Database

Sometimes you need to share some data within your company, and it only exists as a flat file. Sending it around is frustrating, and you can't do further analysis that way either. Slight lets you quickly upload a dataset into your databases, adding documentation too.

Analysing Data in Your Favorite Language

Pulling data from a BI tool into R and Python is usually painful. Instead of solving this, these tools add inadequate coding environments to keep you there instead. Slight delivers data right to your coding environment.

Broad Access Without a Mess

BI tools are often locked down because that's the only way of avoiding a complete mess. But the more your BI tooling is locked down, the larger the shadow infrastructure will be: people will have to work around the restrictions. Slight avoids the cluttered overlap.

Slight or Manual Work

Replacing manual data-focussed workflows is one of our greatest strengths. Other tools shape your processes around their limitations - Slight delivers data where your processes need it to be. We want the fewest possible steps between taking a query running on your machine, and having your stakeholders run it on their schedule, regardless of their SQL knowledge.

Ad-hoc manual work - sending around a CSV, running a quick report on request - becomes laborious as a data analyst. This work can form a layer of shadow infrastructure, where manual flows become accidentally central to the running of your company.

These flows typically aren't already productionized because the cost to doing so is annoyingly high. You can't predict which of today's quick questions becomes tomorrow's shadow infrastructure. Productionizing them all in advance is not workable.

For tasks that revolve around getting data to your domain experts, our goal is to make the cost so low that it's not worth keeping the task out of Slight.

Manual work will never go away entirely, and it probably shouldn't. For true, one-off throwaway queries and scripts, running it on your machine and Slacking someone the answer is perfectly reasonable. Our goal with Slight is to make it less work for you by the second time you have to do a given data task.

Slight or Internal Engineering

This one is perhaps simpler than the others. Your engineers' time, like that of your data analysts, is precious. Why burn it recreating the wheel?

For your most pressing and complex internal tools, it's probably worth the few weeks to build out exactly what's needed. In other cases, it's not worth the maintenance burden.

Slight is intentionally limited to use-cases focussing on your data and databases. We don't intend to be a full-scale internal apps tool. But even when you want to build an internal app, Slight can act as a lightweight testing ground.

Learn More

This page is about comparing Slight to its three closest competitors in a "Jobs to be Done" sense.

There is some overlap with other tools that we don't cover here, mainly tools that aren't primarily for serving non-data team members. This includes notebooks - mainly for exploration and collaboration within a data team - and Airflow / dbt, which are solving data engineering problems.

To learn more about what we're building directly instead of by comparison, see our About page for more details.