TDengine uses a layered configuration system that classifies parameters by where they take effect: server-side only (taosd), client-side only (taosc), or both (both). Understanding these scopes helps you configure your deployment correctly across different environments.
Server-side parameters (taosd)
Server-side parameters apply only within the taosd process. They control core database engine behavior: data storage, query processing, and resource management.
Key examples include monitor, telemetryReporting, dataDir, and tempDir. These settings govern how the server stores data on disk, manages temporary files, handles background monitoring, and reports telemetry information. Since they relate to physical server resources and engine internals, they only make sense in the server context.
Client-side parameters (taosc)
Client-side parameters apply only within the taosc process. They control how applications communicate with the TDengine server: connection management, query strategy, and cache control.
Key examples include maxConnections and timeout. maxConnections limits the number of concurrent connections a single client can open to the server. timeout defines how long the client waits for a server response before treating the request as failed. These parameters let application developers tune client behavior without affecting the server or other clients.
Parameters That Work on Both Sides (both)
This is the most flexible category. Parameters in this group can be configured on either the server side or the client side, depending on your deployment needs.
Connection parameters such as firstEp, fqdn, and serverPort fall here. Query parameters like tagFilterCache and queryPolicy also belong to this group. Logging parameters including logDir and debugFlag round out the list. When both server and client define the same parameter, the client-side configuration generally takes precedence over the server-side configuration.
Quick Reference: Core Parameter Scope Table
| Parameter | Scope |
|---|---|
| firstEp | both |
| fqdn | taosd |
| serverPort | taosd |
| monitor | taosd |
| telemetryReporting | taosd |
| tagFilterCache | both |
| queryPolicy | both |
| dataDir | taosd |
| tempDir | taosd |
| logDir | both |
| debugFlag | both |
| maxConnections | taosc |
| timeout | taosc |
How to Check Parameter Scope
You can inspect parameter values through SQL commands. SHOW VARIABLES displays client-side parameters visible from the current connection. SHOW DNODE VARIABLES displays server-side parameters configured on a specific data node. Comparing output from both commands lets you verify which side holds each parameter and confirm that values are set as intended.
Common Configuration Scenarios and Best Practices
Single-Node Development or Test Environment
Define all parameters in the server-side configuration file. This keeps everything in one place and simplifies setup for development or testing. There is no need to split configuration across multiple files when running a standalone instance.
Multi-Node Production Cluster
Connection-related parameters on each server node need individual configuration. Each dnode in the cluster should have its own fqdn and serverPort set correctly. Client-side parameters can remain in the application configuration, giving each service its own tuning knobs for connection pools and timeouts.
Cloud-Native Deployment (Kubernetes)
Use a ConfigMap or Secret to manage configuration files. Inject dynamic parameters through environment variables. This approach aligns with standard Kubernetes practices and lets you update configuration without rebuilding container images.
Summary
TDengine separates configuration parameters into server-side, client-side, and dual-scope categories. This design keeps core engine behavior unified under server control while giving application developers the flexibility to tune client behavior independently. When both sides define the same parameter, client settings take precedence, which is useful for per-application overrides in shared-cluster environments.
