Filters
The Filters tab allows you to define data perspectives on the connected data sources of a Custom Model. While the Data Sources tab determines which data sources are connected, the Filters tab determines which part of each data source is exposed to this model and its users.
This is the second layer of filtering in Lakehousecat's two-layer architecture:
| Layer | Where | What it controls |
|---|---|---|
| Layer 1 – Data Source Filters | Data Source editor | Which data is physically loaded into ClickHouse |
| Layer 2 – Custom Model Filters | Custom Model Filters tab | Which subset of the loaded data this model exposes as a logical view |
Custom Model filters are implemented as ClickHouse VIEWs. They do not copy or reload data — they create a logical slice of the already-loaded data at query time. This means you can create multiple Custom Models with different filters over the same data source without any additional storage cost or reload.
Why Use Custom Model Filters
Use filters on a Custom Model to:
- Create role-based perspectives — one data source can be the foundation for multiple models, each scoped to a different audience (e.g., Sales Team, Finance Team, Executive View)
- Restrict sensitive data — hide tables or columns that should not be visible to a given group of users
- Apply row-level data restrictions — limit query results to a specific tenant, region, status, or time window
Custom Model filters define what data users can access when they query this model. Sharing a model = granting access to all data it exposes. Configure filters carefully before sharing.
Selecting a Data Source to Filter
The Filters tab shows a dropdown of all data sources connected to this Custom Model. Select a data source to configure its filters. A dot indicator (●) appears next to data sources that already have filters configured.
If no data sources appear, go to the Data Sources tab first and connect at least one data source.
Filter Sections
All filter sections work identically to the Data Source-level filters. For a detailed description of each section, see Data Source Filters.
Schema Filter
Include or exclude specific schemas from this model's view of the data source. Useful when a database contains multiple schemas and only one is relevant to this model's audience.
Table Selection
Select which tables are visible to this model. Check individual tables to include or exclude them.
Column Selections
Per-table column filtering. For each table, choose which columns to include (whitelist) or exclude (blacklist). Use this to hide columns that contain sensitive, irrelevant, or confidential data for this model's audience.
Column Row-Level Filters
Add row-level restrictions equivalent to a WHERE clause. Each filter targets a specific table, column, comparison operator, and value.
Examples:
tenant_id EQUALS acme— restricts all queries to data belonging to a specific tenantregion EQUALS EMEA— scopes the model to European data onlystatus EQUALS active— excludes archived or inactive records
Saving and Clearing Filters
- Save — applies the current filter configuration for the selected data source.
- Clear Filters — removes all filters for the selected data source, making the full dataset visible again.
Each data source is saved independently. You can configure different filters for each connected data source.
Effect on the Semantic Layer
Custom Model filters take effect at query time — they do not require re-running semantic extraction at the data source level. However, after saving or changing filters, run Update Semantic Model from the Operations tab to regenerate the semantic layer to reflect the new data perspective.
Best Practices
- Define filters before running Create Semantic Model so the semantic layer reflects the filtered view from the start.
- Use Column Row-Level Filters for multi-tenant scenarios — one data source, many models, each scoped to its tenant.
- Lock the model after finalizing filters in a production environment to prevent accidental changes.
- Validate the model by testing queries as an end user before sharing.