Sections
Getting started
CLI flags & config
SQL
DDLDMLSELECTFunctions & expressionsTransactions
Clients
HTTP APINative driversPostgreSQL / MySQL wire protocolBinary RPC
Features
RBAC (multi-user)Embeddings (semantic search)File importBackupsDemo showcase mode and .fdb management
Operations
DeploymentArchitectureFileDB on Windows: tray and autostart
Reference
FileDB vs PostgreSQL / MySQL
AI
AI Features: overviewAI Chat and AI AgentSmart Export and AI Import MappingEmbeddings and Hybrid SearchAI setup: providers and presets
Dashboards
Dashboards: overviewDatasets and chartsNo-Code query builderDashboards AI assistantWidgets, grid and filtersPublic links and exportLayout, text cards and KPI comparison

Dashboards: overview

The Dashboards module (/dashboards in the admin panel) lets you build analytics dashboards on top of any FileDB database — no separate BI server, no external dependencies. Data modeling, visualization, and publishing a link all live inside the engine itself.

Architecture: Dataset → Chart → Dashboard

The module is layered DataLens-style, rather than being one flat widget with arbitrary SQL:

Layer What it is Page
Dataset A named, reusable data source: a table/JOIN/CTE plus dimension and measure fields, plus calculated fields "Datasets and charts"
Chart A dataset plus chosen fields (dimension, measures, series) plus a visualization type — no SQL involved "Datasets and charts"
Widget One grid cell on a dashboard: a chart, a No-Code builder query, or raw SQL "Widgets, grid and filters"
Dashboard A named grid of widgets, bound to one database, with global filters "Widgets, grid and filters"

A widget can be built three ways: pick an existing chart, build a query visually in the No-Code builder, or describe what you need in plain language via the AI assistant (or write SQL by hand). Whichever source is used, execution is equally safe (see below).

One read-only choke point

Whichever of the four sources generated the query — a chart, the builder, the AI assistant, or hand-written SQL — execution always goes through the same guard, independent of whether RBAC is configured at all: a leading-keyword whitelist (SELECT/SHOW/EXPLAIN/DESCRIBE/WITH), masking of string literals and comments before any scanning, rejection of stacked statements (SELECT 1; DROP TABLE x), and scanning for DML inside WITH CTEs. This applies to public dashboard links too — an anonymous visitor has no FileDB account at all, so the check can't rely on the caller's role.

HTTP API

Route Access Purpose
GET/POST /api/dashboards authenticated list / create dashboards
GET/PUT/DELETE /api/dashboards/{id} authenticated one dashboard record
POST /api/dashboards/builder/* authenticated No-Code builder — schema, compile, preview, join suggestions
POST /api/dashboards/ai/suggest, /validate authenticated AI assistant
POST /api/dashboards/relations, /relations/test authenticated saved table relationships
POST /api/dashboards/demo/seed authenticated generate demo dashboards on the current DB
POST /api/dashboards/share, /revoke authenticated, write role create / revoke a public link
POST /api/dashboards/share/validate, /query, /export public, rate-limited open a shared dashboard, fetch widget data, download CSV

More on the "Datasets and charts", "No-Code query builder", "Dashboards AI assistant", "Widgets, grid and filters", and "Public links and export" pages.

Related pages
← Previous
AI setup: providers and presets
Next →
Datasets and charts