Apache Superset — Administrator & Developer Guide

1. Architecture Overview

Apache Superset is an open-source business intelligence platform built on a Python/Flask backend with a React/TypeScript frontend. It connects to external databases via SQLAlchemy, executes queries on behalf of users, and renders interactive visualizations and dashboards in the browser.

The system follows a multi-tier architecture: a Flask web application serves the UI and REST API, Celery workers handle asynchronous tasks (reports, thumbnails, long-running queries), Redis provides caching and message brokering, and a relational database (PostgreSQL or MySQL) stores all metadata.

Architecture Diagram

                        +------------------+
                        |   Web Browser    |
                        +--------+---------+
                                 |
                                 | HTTPS
                                 v
                     +-----------+-----------+
                     |  Reverse Proxy (nginx |
                     |  / Traefik / Ingress) |
                     +-----------+-----------+
                                 |
              +------------------+------------------+
              |                  |                  |
              v                  v                  v
    +---------+------+  +--------+-------+  +-------+--------+
    |  Superset App  |  | Celery Worker  |  | Celery Beat    |
    |  (Flask/       |  | (async tasks,  |  | (scheduler,    |
    |   Gunicorn)    |  |  reports,      |  |  cron-based    |
    |  :8088         |  |  thumbnails)   |  |  triggers)     |
    +--------+-------+  +--------+-------+  +-------+--------+
             |                   |                  |
    +--------+---------+---------+---------+--------+
    |                  |                   |
    v                  v                   v
+---+---+       +------+------+    +------+------+
| Redis |       | PostgreSQL  |    | External    |
| :6379 |       | (metadata)  |    | Databases   |
+-------+       | :5432       |    | (data       |
                +-------------+    |  sources)   |
                                   +-------------+

Optional services:

+------------------+     +------------------+
| WebSocket Server |     |   MCP Service    |
| (Node.js, Redis  |     | (FastMCP, stdio  |
|  streams)        |     |  or HTTP, :5008) |
+------------------+     +------------------+

Component Inventory

Technology Stack

Data Flow

Chart rendering:

1. User configures chart in Explore UI
2. Frontend sends form data to /api/v1/chart/data/ or the Explore API
3. Backend resolves dataset, builds SQL query from form data
4. SQLAlchemy executes query against the external database
5. Results are post-processed (aggregation, time comparison, percentage calculations)
6. JSON results returned to frontend for ECharts/D3/table rendering
7. Results optionally cached in Redis with a generated cache key

Report execution:

1. Celery Beat triggers reports.scheduler every minute
2. Scheduler identifies due reports based on cron schedule and timezone
3. Worker executes the report: renders dashboard/chart screenshot or runs SQL query
4. Output (PNG/PDF/CSV) delivered via email (SMTP) or Slack webhook
5. Execution logged; stale logs pruned daily at 00:10

Note

The SupersetAppInitializer class in superset/initialization/__init__.py orchestrates all component registration: 30+ REST API views, web views, menu items, and Celery configuration are wired together during app startup via init_views().

2. System Requirements

Hardware

Software Dependencies

Key Python Dependencies

Key Frontend Dependencies

3. Configuration Reference

Configuration Files

Environment Variables

Important

SUPERSET_SECRET_KEY is the most critical configuration value. If not set, Superset will refuse to start in non-debug environments. Generate a strong key with openssl rand -base64 42 and store it securely. Changing this key invalidates all existing sessions and encrypted database passwords — run superset re_encrypt_secrets after changing it.

Frontend Environment Variables

MCP Service Environment Variables

Caching Configuration

The Docker development config sets up Redis-backed caching:

CACHE_CONFIG = {
    "CACHE_TYPE": "RedisCache",
    "CACHE_DEFAULT_TIMEOUT": 300,
    "CACHE_KEY_PREFIX": "superset_",
    "CACHE_REDIS_HOST": REDIS_HOST,
    "CACHE_REDIS_PORT": REDIS_PORT,
    "CACHE_REDIS_DB": REDIS_RESULTS_DB,
}

Configure separate caches for different subsystems:

• CACHE_CONFIG — default cache
• DATA_CACHE_CONFIG — chart data results
• FILTER_STATE_CACHE_CONFIG — native filter state
• EXPLORE_FORM_DATA_CACHE_CONFIG — explore form state

Celery Configuration

class CeleryConfig:
    broker_url = f"redis://{REDIS_HOST}:{REDIS_PORT}/{REDIS_CELERY_DB}"
    result_backend = f"redis://{REDIS_HOST}:{REDIS_PORT}/{REDIS_RESULTS_DB}"
    worker_prefetch_multiplier = 1
    task_acks_late = False
    imports = (
        "superset.sql_lab",
        "superset.tasks.scheduler",
        "superset.tasks.thumbnails",
        "superset.tasks.cache",
    )
    beat_schedule = {
        "reports.scheduler": {
            "task": "reports.scheduler",
            "schedule": crontab(minute="*", hour="*"),
        },
        "reports.prune_log": {
            "task": "reports.prune_log",
            "schedule": crontab(minute=10, hour=0),
        },
    }

CELERY_CONFIG = CeleryConfig

Tip

For production, set worker_prefetch_multiplier = 1 and task_acks_late = True to prevent task loss if a worker crashes mid-execution. Adjust concurrency via CELERYD_CONCURRENCY (default: 2 for dev).

Feature Flags Reference

Key Application Settings

4. Deployment & Scaling

Docker Compose Deployment

The standard Docker Compose deployment includes:

Docker entrypoint boot modes:

Initialization scripts:

• docker-init.sh — database migration, admin user creation, role setup, optional example loading
• docker-bootstrap.sh — dependency installation and configuration bootstrap
• run-server.sh — Gunicorn production startup

Gunicorn Configuration

Tip

For production, set SERVER_WORKER_AMOUNT to 2 * CPU_cores + 1. Use gthread worker class with 20 threads for best throughput with database-bound workloads. Set GUNICORN_TIMEOUT to at least 120 for complex dashboard loads.

Kubernetes (Helm) Deployment

The Helm chart (v0.15.4, appVersion 5.0.0) deploys Superset with:

Chart dependencies:

• PostgreSQL 16.7.27 (Bitnami, OCI registry)
• Redis 17.9.4 (Bitnami, OCI registry)

Key Helm values:

# Image
image:
  repository: apachesuperset.docker.scarf.sh/apache/superset
  pullPolicy: IfNotPresent

# Service
service:
  type: ClusterIP
  port: 8088

# Ingress
ingress:
  enabled: false
  # annotations, hosts, tls configuration

# SupersetNode (main application)
supersetNode:
  replicas:
    enabled: true
    replicaCount: 1
  autoscaling:
    minReplicas: 1
    maxReplicas: 100
    targetCPUUtilizationPercentage: 80

# Database connections
supersetNode:
  connections:
    db_type: postgresql
    db_host: "{{ .Release.Name }}-postgresql"
    db_port: "5432"
    db_user: superset
    db_pass: superset
    db_name: superset
    redis_host: "{{ .Release.Name }}-redis-headless"
    redis_port: "6379"

Health probes:

Configuration injection:

Init containers:

• wait-for-postgres — uses dockerize to wait for database readiness (timeout: 120s)
• Workers additionally wait for Redis before starting

Warning

The default Helm values set runAsUser: 0 (root). For production Kubernetes deployments, change this to a non-root user (1000+) and ensure volume permissions match.

Scaling Guidelines

5. Operations

Health Monitoring

Health check endpoints:

Note

The health endpoint at http://localhost:${SUPERSET_PORT}/${SUPERSET_APP_ROOT}/health is the standard target for Docker, Kubernetes, and load balancer health checks.

Celery Task Management

Monitoring tasks:

The Task REST API (/api/v1/tasks/) provides:

• GET / — list tasks with filters (type, status, scope)
• GET /<uuid> — retrieve task details
• DELETE /<uuid> — cancel a running task
• GET /<uuid>/status — check task status

Common Celery tasks:

Thumbnail Management

Compute thumbnails for all dashboards and charts:

superset compute_thumbnails

Database Operations

Update a database URI:

superset set_database_uri -d "My Database" -u "postgresql+psycopg2://new_user:pass@host/db"

Use --skip_create / -s to prevent auto-creating the database if it does not exist.

Re-encrypt secrets after key rotation:

superset re_encrypt_secrets --previous_secret_key "old_key"

Caution

If SUPERSET_SECRET_KEY is changed without running re_encrypt_secrets, all stored database passwords become unreadable. Always back up the metadata database before key rotation.

Import/Export Operations

Full asset export (API):

curl -X GET "http://localhost:8088/api/v1/assets/export/" \
  -H "Authorization: Bearer $TOKEN" \
  -o superset_assets_$(date +%Y%m%d).zip

Full asset import (API):

curl -X POST "http://localhost:8088/api/v1/assets/import/" \
  -H "Authorization: Bearer $TOKEN" \
  -F "bundle=@superset_assets.zip" \
  -F "passwords={\"databases/My_DB.yaml\": \"db_password\"}" \
  -F "ssh_tunnel_passwords={}" \
  -F "ssh_tunnel_private_keys={}" \
  -F "ssh_tunnel_private_key_passwords={}" \
  -F "encrypted_extra_secrets={}"

CLI export/import:

Legacy format commands (for older Superset versions):

Note

The modern ZIP-based format supports sparse updates (--sparse flag) and handles SSH tunnel credentials, encrypted extras, and database passwords during import.

Backup Strategy

• [x] Back up PostgreSQL metadata database daily
• [x] Export assets via API or CLI before major upgrades
• [x] Store SUPERSET_SECRET_KEY securely and separately
• [ ] Test restore procedure quarterly
• [ ] Monitor disk usage for Redis persistence

6. Performance

Caching Strategy

Superset uses a multi-layer caching architecture:

Cache key generation: Superset generates cache keys from a dictionary of query parameters using generate_cache_key(). Cache entries track the datasource for invalidation purposes.

ETag caching: The @etag_cache decorator provides HTTP-level caching with Last-Modified, Expires, and conditional request (If-None-Match) support for API responses.

Cache warming: Pre-warm chart caches using:

POST /api/v1/chart/<id>/warm_up_cache

Query Optimization

• Set ROW_LIMIT appropriately (default: 50,000) — lower limits reduce response time
• Use SAMPLES_ROW_LIMIT (default: 1,000) for data previews
• Enable query cost estimation for databases that support it
• Configure SQLLAB_CTAS_NO_LIMIT = True to avoid row limits on CTAS operations
• Use SQLLAB_TIMEOUT to prevent runaway queries

Frontend Performance

• Enable NODE_OPTIONS="--max-old-space-size=8192" for builds
• The frontend uses lazy-loaded React components for code splitting
• Webpack bundle analyzer available via BUNDLE_ANALYZER=true
• TypeScript checking can be skipped during development with DISABLE_TS_CHECKER=true

Tip

For dashboards with many charts, use the dashboard tab feature to split content across tabs. Only visible tabs execute queries, reducing initial load time.

7. Security

Authentication

Superset uses Flask-AppBuilder for authentication, supporting:

• Database authentication — username/password stored in the metadata DB
• OAuth/OpenID — Google OAuth, Okta, Auth0, etc.
• LDAP — Active Directory / LDAP integration
• Remote user — trust headers from a reverse proxy

Configure via AUTH_TYPE and related settings in superset_config.py.

User registration: Controlled by AUTH_USER_REGISTRATION. When enabled, new users can self-register with email activation via SupersetRegisterUserView.

Authorization (RBAC)

Superset implements role-based access control through Flask-AppBuilder:

Built-in roles:

Custom roles can be created with fine-grained permissions on specific data sources, views, and actions.

Row-Level Security (RLS)

RLS rules add automatic WHERE clauses to queries based on user roles:

• Rules map roles to tables with SQL filter clauses
• Multiple filter types supported for different security models
• Group keys organize rules logically
• Rules compose — multiple rules on the same table are combined

Security REST API:

Guest Tokens (Embedded Security)

Guest tokens enable secure embedded dashboard access:

# Token request payload
{
    "user": {"username": "guest", "first_name": "Guest"},
    "resources": [{"type": "dashboard", "id": "<dashboard-uuid>"}],
    "rls": [{"clause": "team_id = 'sales'"}]
}

The embedded SDK automatically refreshes tokens before expiry using JWT-based timing calculations.

Database Connection Security

URI validation: The check_sqlalchemy_uri() function enforces a blocklist:

• Blocked: SQLite, Shillelagh (local file access risk)
• Administrators can customize the blocklist via configuration

Encrypted credentials: Database passwords are stored encrypted using SUPERSET_SECRET_KEY. SSH tunnel credentials (passwords, private keys) are similarly encrypted.

Warning

Never expose SUPERSET_SECRET_KEY in logs, version control, or error messages. If compromised, rotate the key immediately and run superset re_encrypt_secrets to re-encrypt all stored credentials.

Security Headers

Flask-Talisman provides security headers (CSP, HSTS, etc.). Controlled via TALISMAN_ENABLED (default: True).

Distributed Locking

Superset uses distributed locks (via the key-value store) to prevent concurrent operations on shared resources. Lock entries are stored in the KeyValueEntry table with the lock resource type.

8. Developer Internals

Repository Structure

apache/superset/
+-- superset/                    # Python backend (Flask application)
|   +-- __init__.py              # App factory, extensions
|   +-- app.py                   # create_app() factory function
|   +-- config.py                # Default configuration (2000+ lines)
|   +-- initialization/          # SupersetAppInitializer
|   +-- cli/                     # CLI commands (Click)
|   +-- views/                   # Web views and API endpoints
|   +-- models/                  # SQLAlchemy models
|   +-- daos/                    # Data Access Objects
|   +-- commands/                # Business logic commands
|   +-- security/                # SupersetSecurityManager
|   +-- db_engine_specs/         # 73 database engine specifications
|   +-- charts/                  # Chart REST API and models
|   +-- dashboards/              # Dashboard REST API and models
|   +-- datasets/                # Dataset REST API and models
|   +-- databases/               # Database REST API and models
|   +-- sqllab/                  # SQL Lab API and execution
|   +-- reports/                 # Report scheduling API
|   +-- tags/                    # Tagging system
|   +-- key_value/               # Key-value store
|   +-- embedded/                # Embedded dashboard support
|   +-- mcp_service/             # Model Context Protocol service
|   +-- tasks/                   # Celery tasks and task API
|   +-- utils/                   # Utility functions (45 files)
|   +-- common/                  # Shared enums and utilities
|   +-- extensions/              # Flask extensions and meta DB
|   +-- migrations/              # Alembic database migrations
|   +-- sql/                     # SQL parsing and validation
|   +-- sql_validators/          # SQL validation engines
|   +-- importexport/            # Import/export API
|   +-- row_level_security/      # RLS API
|   +-- themes/                  # Theme definitions
|   +-- translations/            # i18n translation files
|   +-- examples/                # Example datasets and dashboards
|   +-- async_events/            # Async event streaming
|   +-- thumbnails/              # Screenshot generation
|   +-- explore/                 # Explore API
|   +-- datasource/              # Datasource API
|   +-- annotation_layers/       # Annotation API
|   +-- css_templates/           # CSS template API
|   +-- temporary_cache/         # Temporary cache entries
|   +-- advanced_data_type/      # Advanced data type handling
|   +-- distributed_lock/        # Distributed locking
|   +-- cachekeys/               # Cache key tracking
+-- superset-frontend/           # TypeScript/React frontend
|   +-- src/                     # Application source
|   |   +-- components/          # Shared React components
|   |   +-- views/               # Page-level views
|   |   +-- features/            # Feature modules
|   |   +-- explore/             # Chart explore interface
|   |   +-- SqlLab/              # SQL Lab IDE
|   |   +-- embedded/            # Embedded dashboard
|   |   +-- utils/               # Frontend utilities (58 files)
|   |   +-- hooks/               # React hooks (13 files)
|   |   +-- middleware/           # Redux middleware
|   |   +-- core/                # Core commands and utilities
|   |   +-- theme/               # Theme utilities
|   +-- plugins/                 # Visualization plugins
|   |   +-- plugin-chart-echarts/ # ECharts-based charts
|   |   +-- plugin-chart-table/  # Table visualization
|   |   +-- plugin-chart-pivot-table/ # Pivot table
|   |   +-- plugin-chart-ag-grid-table/ # AG Grid table
|   |   +-- preset-chart-deckgl/ # deck.gl geospatial charts
|   |   +-- plugin-chart-word-cloud/ # Word cloud
|   |   +-- plugin-chart-handlebars/ # Handlebars template chart
|   |   +-- plugin-chart-cartodiagram/ # Cartodiagram
|   |   +-- plugin-chart-point-cluster-map/ # Point cluster map
|   |   +-- legacy-plugin-chart-*/ # Legacy chart types
|   |   +-- legacy-preset-chart-nvd3/ # Legacy NVD3 charts
|   +-- packages/                # Shared packages
|   |   +-- superset-core/       # @apache-superset/core
|   |   +-- superset-ui-core/    # @superset-ui/core
|   |   +-- superset-ui-chart-controls/ # Chart control components
|   |   +-- superset-ui-switchboard/ # Cross-frame communication
|   |   +-- generator-superset/  # Yeoman plugin generator
|   +-- playwright/              # E2E tests
|   +-- cypress-base/            # Cypress tests
+-- superset-embedded-sdk/       # Embedded dashboard SDK
+-- superset-extensions-cli/     # Extension management CLI
+-- superset-websocket/          # WebSocket service (Node.js)
+-- superset-core/               # New core package
+-- helm/superset/               # Kubernetes Helm chart
+-- docker/                      # Docker configuration
+-- docs/                        # Docusaurus documentation site
+-- tests/                       # Backend test suite
+-- scripts/                     # Build and utility scripts
+-- RELEASING/                   # Release management tools

REST API Reference

Superset exposes 30+ REST API resource groups registered during initialization. Key APIs:

Data Layer APIs:

Visualization APIs:

Administrative APIs:

Utility APIs:

Database API extended routes:

Dashboard API extended routes:

CLI Command Reference

The superset CLI is registered as a console script entry point: superset=superset.cli.main:superset.

Core commands:

Data management:

Administration:

Visualization migration:

MCP service:

Extensions CLI (separate package: superset-extensions-cli):

Module Reference (Key Backend Modules)

superset/app.py — Application factory. create_app() loads configuration from the SUPERSET_CONFIG environment variable (default: superset.config), initializes SupersetAppInitializer, and returns the Flask app. Supports APPLICATION_ROOT for subdirectory deployments.

superset/initialization/__init__.py — SupersetAppInitializer orchestrates startup: registers 30+ API views, configures Celery, sets up menu items, runs pre/post-init hooks.

superset/models/core.py — Core SQLAlchemy models including Database (connection management with encrypted passwords, OAuth2, SSH tunnels, capabilities like allow_run_async, allow_file_upload, allow_ctas, allow_cvas, allow_dml), CssTemplate, Theme, AnnotationLayer, Annotation, CacheKey, KeyValue.

superset/db_engine_specs/ — 73 database engine specification modules. Each spec extends BaseEngineSpec with database-specific behavior: time grain expressions, query cost estimation, error message parsing, connection validation, schema browsing, file upload support. Specs are loaded dynamically via load_engine_specs() and can be extended via the superset.db_engine_specs entry point group.

superset/security/manager.py — SupersetSecurityManager extends Flask-AppBuilder's security manager with Superset-specific authorization: database URI validation, guest token management, row-level security enforcement, permission syncing.

superset/sql/parse.py — SQL parsing engine (51K chars). Parses SQL for validation, extracts table references, validates clauses, and handles Jinja template rendering.

superset/daos/ — 19 Data Access Object modules providing database query patterns for all entity types.

superset/commands/ — Business logic layer implementing the command pattern. Commands encapsulate create, update, delete, export, and import operations with validation and authorization.

superset/views/ — 29 view modules including Api (core query execution), SupersetAuthView (login), SupersetRegisterUserView (registration), and health endpoints.

superset/utils/ — 45 utility modules including caching (cache.py), core utilities (core.py), decorators, date parsing, SQL formatting, and email sending.

superset/extensions/ — 15 Flask extension modules including the meta database (metadb.py — registers Superset as a Shillelagh-backed SQLAlchemy dialect at superset://), local extensions watcher, and feature flag manager.

Extension System

The @apache-superset/core package (v0.1.0-rc2) provides the extension API:

Extension contribution types:

Extension manifest format (JSON):

• id — composite ID (publisher.name)
• publisher, name, displayName, version
• permissions, dependencies
• frontend.remoteEntry, frontend.moduleFederationName
• backend.entrypoint

Extensions use Module Federation for frontend loading and standard Python entry points for backend integration.

WebSocket Service Architecture

The WebSocket service (superset-websocket/) is a standalone Node.js server:

• Transport: WebSocket over HTTP upgrade
• Auth: JWT-based (extracted from cookies, configurable algorithms)
• Backend: Redis Streams for event delivery
• Metrics: StatsD integration for monitoring
• Lifecycle: Ping/pong keep-alive, garbage collection for stale channels

Configuration: port, logging, Redis connection, JWT settings, socket management (response timeout, ping interval, GC interval).

MCP Service Architecture

The MCP service (superset/mcp_service/) implements the Model Context Protocol:

• Server: FastMCP with Flask app context integration
• Transport: Stdio (default) and HTTP modes
• Middleware stack: Response size guard, logging, error handling, content stripping
• Tool registration: Automatic tool discovery and registration
• Security: Suppresses non-essential output in stdio mode

Database Engine Specification System

The superset/db_engine_specs/ directory contains 73 engine specification files implementing BaseEngineSpec. The system:

1. Discovers specs via pkgutil.iter_modules() at startup
2. Loads additional specs from the superset.db_engine_specs entry point group
3. Matches specs to connections using get_engine_spec(backend, driver)
4. Falls back to backend-only matching if no driver-specific spec exists

Each spec provides: time grain expressions, date truncation SQL, query cost estimation, error message parsing and categorization, connection parameter validation, catalog/schema/table browsing, file upload handlers, and SQL dialect adjustments.

Testing Strategy

Backend testing:

Run tests with:

scripts/tests/run.sh
scripts/tests/run.sh --module tests/charts/api_tests.py
scripts/tests/run.sh --module tests/charts/api_tests.py::TestChartApi::test_get_charts --no-init

Frontend testing:

Code quality tools:

Entity Relationship Diagram

Generate an ERD of the Superset metadata schema:

python scripts/erd/erd.py -o superset_erd.png

Contributing

Development setup:

1. Clone the repository
2. Set up Python virtual environment with pip install -e .
3. Set up frontend with cd superset-frontend && npm ci
4. Start PostgreSQL and Redis (via Docker or locally)
5. Initialize: superset db upgrade && superset fab create-admin && superset init
6. Start backend: superset run -p 8088 --with-threads --reload
7. Start frontend: cd superset-frontend && npm run dev-server

Documentation development:

cd docs
yarn install
yarn start          # Quick start (smart generation)
yarn start:full     # Full start (regenerate all)

The docs site uses Docusaurus 3 with four independent versioned sections: User Documentation, Admin Documentation, Developer Docs, and Component Playground. Always use the automated versioning scripts:

yarn version:add:docs 1.2.0
yarn version:remove:docs 1.0.0

Warning

Do NOT use native Docusaurus versioning commands (yarn docusaurus docs:version). They will create version files but fail to update versions-config.json, causing versions to not appear in dropdown menus.

Potential Improvements

Based on source analysis:

• API server decomposition: api_server.py equivalent modules could be split into domain-specific routers for maintainability
• SQL parsing consolidation: The 51K-char sql/parse.py handles multiple concerns (parsing, validation, Jinja rendering) that could be separated
• Engine spec metadata linting: The lint_metadata.py tool validates engine spec completeness — running it regularly with --strict would catch missing required fields
• Extension system maturity: The extension CLI and @apache-superset/core package are at v0.1.0-rc2 — the contribution model (views, commands, menus, editors) is well-designed but still pre-release

9. Integration Points

Embedded Dashboard SDK

The @superset-ui/embedded-sdk provides:

SDK capabilities:

• Automatic guest token refresh before expiry
• Iframe sandbox and security configuration
• Filter synchronization and data mask observation
• Permalink URL resolution with custom callbacks
• Theme configuration (default/dark/system)
• Chart state and data payload access
• Dashboard scroll size measurement for responsive sizing

Superset Meta Database

When ENABLE_SUPERSET_META_DB is enabled, Superset registers:

• SQLAlchemy dialect: superset:// (via superset.extensions.metadb.SupersetAPSWDialect)
• Shillelagh adapter: superset.extensions.metadb.SupersetShillelaghAdapter

This allows querying Superset's own data through SQL Lab as if it were an external database.

Email Integration

Superset sends emails for:

• Report delivery (SMTP with optional SSL/TLS)
• Alert notifications
• User registration activation

Configure SMTP settings in superset_config.py. Email content supports inline images and attachments. An email mutator hook allows customizing recipients and content programmatically.

Slack Integration

Reports and alerts can deliver to Slack channels when configured with a Slack API token. Notifications include chart screenshots, dashboard PDFs, or CSV data attachments.

Key-Value Store

The KeyValueEntry model provides a generic key-value store used internally for:

Entries support expiry, UUID-based keys, and multiple codecs (JSON, Pickle). Maximum value size: 2^24-1 bytes (16 MB).

Async Events (WebSocket)

The WebSocket service streams events from Redis Streams to connected browser clients:

• Channel-based message filtering
• JWT authentication from cookies
• Automatic keep-alive via ping/pong
• StatsD metrics for monitoring
• Garbage collection for stale connections

Database-Specific Integrations

The 73 engine specs in superset/db_engine_specs/ provide deep integration with specific databases:

• OAuth2 authentication — for databases requiring token-based auth
• IAM authentication — AWS IAM auth for Redshift, Athena, etc.
• Multi-catalog support — browsing catalogs, schemas, and tables
• Query cost estimation — pre-execution cost preview
• File upload — CSV, Excel, Parquet upload with database-specific handling
• SSH tunneling — secure connections through SSH bastions

Note

Third-party database engine specs can be registered via the superset.db_engine_specs Python entry point group, allowing custom databases to integrate without modifying Superset core.