Lightdash gives you two powerful ways to control what data your users see: filters and parameters.
On the surface, they can look very similar. Both can narrow down results and help people focus on the right slice of data. But parameters aren’t just another kind of filter. They unlock flexibility, reusability, and customisation that filters alone can’t match.
So, when should you reach for parameters instead of a regular filter? Let’s break it down.
Parameters in a Nutshell
lightdash.config.yml and can be reused anywhere in your Lightdash project. They can:- Drive dynamic SQL in dimensions, metrics, joins, and calculations.
- Be set at runtime by the data consumer.
- Have saved values at the chart or dashboard level for consistent filtering.
For example, you could define a currency parameter that lets users toggle between USD, EUR, and GBP in your revenue calculations. Instead of creating separate measures for each currency, you’d define the conversion logic once in your model and let the parameter control which exchange rate gets applied keeping your charts consistent and easy to maintain. While useful, this does require additional upfront work such as adjusting your metrics to contain the necessary logic for the parameter adjustment.
Filters in a Nutshell
- Apply to fields already defined in your data model.
- Are chart-specific unless you apply them at the dashboard level.
- Don’t require you to edit
lightdash.config.ymlnor require edits to your metrics.
The Overlap and the Difference
Both parameters and filters can achieve the same visible outcome for the user, like showing “only EMEA orders.”
The difference lies in where the filtering logic lives and how reusable it is:
| Feature | Parameters | Filters |
|---|---|---|
| Defined in | lightdash.config.yml | Lightdash UI |
| Works inside SQL definitions | ✅ | ❌ |
| Reusable across multiple models & joins without redefinition | ✅ | ❌ |
| Data consumer can change without editing SQL | ✅ | ✅ |
| Saved at chart & dashboard level | ✅ | ✅ |
| Requires upfront setup | ✅ | ❌ |
When to Use Parameters Instead of Filters
1. You need the value inside SQL
If your logic needs to live inside a dimension, metric, join, or table calculation, only parameters will work. For example…
CASE
WHEN ${lightdash.parameters.currency} = 'USD' THEN ${TABLE}.revenue_usd
WHEN ${lightdash.parameters.currency} = 'EUR' THEN ${TABLE}.revenue_usd * ${TABLE}.eur_conversion_rate
WHEN ${lightdash.parameters.currency} = 'GBP' THEN ${TABLE}.revenue_usd * ${TABLE}.gbp_conversion_rate
ELSE ${TABLE}.revenue_usd
END
A filter couldn’t change the behaviour of that SQL, only a parameter can.
2. You want consistent behaviour across multiple charts
If you have a “cut-off date,” “currency,” or “region” that needs to work exactly the same way across dozens of queries, a parameter is your best friend. Instead of manually adding the same filter to every chart (and hoping nobody forgets one), you define it once in your lightdash.config.yml and then adjust your metrics and dimensions accordingly.
From then on:
- Every chart that references the metric or parameter will use the same logic.
- Changing defaults (e.g., moving the cut-off date from January to March) automatically updates all charts using that parameter.
- Option lists (like available currencies) stay in sync everywhere without stale dropdowns lurking in old dashboards.
- You’re building reusable data products
If your team is creating template dashboards or “starter packs” for other teams, parameters make them far more portable and less fragile. Instead of handing over a dashboard with a list of “Don’t forget to set these filters” instructions, you can bake the variable logic right into the model.
Imagine you’re building a customer lifecycle dashboard that compares performance across different lifecycle stages: New, Active, Churned. With a lifecycle_stage parameter, every chart, join, and calculation in that dashboard responds to the same stage selection.
This allows your team to ship one dashboard that works for every stage. Users don’t accidentally misconfigure a filter and break the logic. Most importantly, you avoid maintaining three separate dashboards.
Quick Decision Guide
Use a parameter when:
- The value needs to be referenced inside SQL.
- You want reusability and consistency across data products.
Use a filter when:
- You just want to quickly slice a chart or dashboard.
- You don’t need the value inside your data model.
While there’s overlap in what parameters and filters can do in Lightdash, parameters shine when you’re designing for scale, reuse, and maintainability. If you’re starting small, filters are fine. But when you notice you’re applying the same filter again and again, or you wish a filter could actually change your SQL logic, it’s probably time to reach for parameters.
Not sure what’s the next move for your semantic layer? At Driftwave, we help teams adopt modern analytics tools like Lightdash, so you can spend less time firefighting and more time building. We ensure that your Lightdash instance is set up, maintained, and scaled according to your needs, so you can focus on the insights, not the infrastructure.
In addition to hosting, our expert consulting services are designed to help you implement a modern data stack that supports your business goals. We guide you through the process of selecting the right tools, optimizing your data workflows, and empowering your teams to unlock the full potential of your data.