ClickHouse DB::Exception: Support is disabled (Code: 344)

The "DB::Exception: Support is disabled" error in ClickHouse indicates that a requested feature or capability is not available because it was disabled at compile time or through a setting. The SUPPORT_IS_DISABLED error code (code 344) is most commonly raised when a query uses a feature that is gated behind an allow_experimental_* or similar setting that is turned off, and less commonly when a build was compiled without an optional component.

Impact

The specific feature or function is unavailable. Queries using the disabled feature will fail. This does not affect other ClickHouse functionality. Users need to either enable the feature (if it is a configuration option) or use a different ClickHouse build that includes the feature.

Common Causes

1. Using a ClickHouse build compiled without support for a specific library (e.g., HDFS, S3, Kerberos, ICU)
2. A feature gated behind an allow_experimental_* setting that is not enabled
3. A ClickHouse distribution (e.g., minimal builds, certain OS packages) that excludes optional components
4. Server configuration explicitly disabling a feature for security or resource reasons
5. Using a ClickHouse Cloud tier that does not support certain features
6. Attempting to use a storage engine or table function that requires a library not linked in the build

Troubleshooting and Resolution Steps

1. Check the full error message to identify which feature is disabled:

   SELECT event_time, query, exception
   FROM system.query_log
   WHERE exception LIKE '%disabled%'
   ORDER BY event_time DESC
   LIMIT 10;
   

2. Check if the feature requires an experimental setting to be enabled:

   SELECT name, value, description
   FROM system.settings
   WHERE name LIKE '%allow_experimental%' AND name LIKE '%feature_name%';
   

3. Enable the experimental feature if applicable:

   SET allow_experimental_<feature_name> = 1;
   

4. Check which features are compiled into your ClickHouse build:

   SELECT * FROM system.build_options;
   

5. If the feature requires a different build, check the installed build options:

   SELECT * FROM system.build_options WHERE name LIKE '%HDFS%' OR name LIKE '%S3%';
   

6. If using a package manager, switch to the full build:

   # For Ubuntu/Debian
   sudo apt install clickhouse-server clickhouse-client
   # Ensure you are using the official ClickHouse repository, not a minimal build
   

7. For configuration-disabled features, check and update the server config:

   grep -r 'disabled\|enable' /etc/clickhouse-server/config.d/*.xml
   

Best Practices

• Use official ClickHouse builds from the ClickHouse repository, which include all standard features.
• Document which experimental features your workload depends on and ensure they are enabled in all environments.
• When deploying ClickHouse, verify that required features are available by running a test query before the application goes live.
• Track ClickHouse release notes for features graduating from experimental to stable, as the enabling settings may change.
• If building ClickHouse from source, ensure all required CMake flags are set for the features you need.

Frequently Asked Questions

Q: How do I know which features are compiled into my ClickHouse build?
A: Query SELECT * FROM system.build_options to see all compile-time options. Features like HDFS, S3, MySQL, PostgreSQL, and others show up as build flags.

Q: Can I enable a compile-time disabled feature without rebuilding?
A: No. If a feature was excluded at compile time, you need a different build that includes it. Configuration-level features can be enabled at runtime, but compile-time features cannot.

Q: Why are some features behind experimental settings?
A: ClickHouse marks features as experimental when they are still being refined and may have breaking changes in future versions. The allow_experimental_* settings are safety gates that prevent accidental use of unstable features in production.