database/sql or “standard” API allows you to use the client in scenarios where application code should be agnostic of the underlying databases by conforming to a standard interface. This comes at some expense - additional layers of abstraction and indirection and primitives which aren’t necessarily aligned with ClickHouse. These costs are, however, typically acceptable in scenarios where tooling needs to connect to multiple databases.
Additionally, this client supports using HTTP as the transport layer - data will still be encoded in the native format for optimal performance.
Connecting
Connection can be achieved either via a DSN string with the formatclickhouse://<host>:<port>?<query_option>=<value> and Open method or via the clickhouse.OpenDB method. The latter isn’t part of the database/sql specification but returns a sql.DB instance. This method provides functionality such as profiling, for which there are no obvious means of exposing through the database/sql specification.
conn variable has been created and is available.
Connection settings
Most configuration options are shared with the ClickHouse API. See Configuration for shared settings. The following SQL-specific DSN parameters are available:hosts- comma-separated list of single address hosts for load-balancing and failover - see Connecting to Multiple Nodes.username/password- auth credentials - see Authenticationdatabase- select the current default databasedial_timeout- a duration string is a possibly signed sequence of decimal numbers, each with optional fraction and a unit suffix such as300ms,1s. Valid time units arems,s,m.connection_open_strategy-random/in_order(defaultrandom) - see Connecting to Multiple Nodesround_robin- choose a round-robin server from the setin_order- first live server is chosen in specified order
debug- enable debug output (boolean value)compress- specify the compression algorithm -none(default),zstd,lz4,gzip,deflate,br. If set totrue,lz4will be used. Onlylz4andzstdare supported for native communication.compress_level- Level of compression (default is0). See Compression. This is algorithm specific:gzip--2(Best Speed) to9(Best Compression)deflate--2(Best Speed) to9(Best Compression)br-0(Best Speed) to11(Best Compression)zstd,lz4- ignored
secure- establish secure SSL connection (default isfalse)skip_verify- skip certificate verification (default isfalse)block_buffer_size- allows you to control the block buffer size. SeeBlockBufferSize. (default is2)
Connecting over HTTP
By default, connections are established over the native protocol. For users needing HTTP, this can be enabled by either modifying the DSN to include the HTTP protocol or by specifying the Protocol in the connection options.Sessions
HTTP onlySessions are only needed when using the HTTP transport. Native TCP connections have a built-in session automatically.
session_id as a setting to enable session-bound features such as temporary tables.
Execution
Once a connection has been obtained, you can issuesql statements for execution via the Exec method.
ExecContext if this is needed - see Using Context.
Batch insert
Batch semantics can be achieved by creating asql.Tx via the Being method. From this, a batch can be obtained using the Prepare method with the INSERT statement. This returns a sql.Stmt to which rows can be appended using the Exec method. The batch will be accumulated in memory until Commit is executed on the original sql.Tx.
Querying rows
Querying a single row can be achieved using theQueryRow method. This returns a *sql.Row, on which Scan can be invoked with pointers to variables into which the columns should be marshaled. A QueryRowContext variant allows a context to be passed other than background - see Using Context.
Query method. This returns a *sql.Rows struct on which Next can be invoked to iterate through the rows. QueryContext equivalent allows passing of a context.
Async insert
Asynchronous inserts can be achieved by executing an insert via theExecContext method. This should be passed a context with asynchronous mode enabled, as shown below. This allows the user to specify whether the client should wait for the server to complete the insert or respond once the data has been received. This effectively controls the parameter wait_for_async_insert.
Parameter binding
The standard API supports the same parameter binding capabilities as the ClickHouse API, allowing parameters to be passed to theExec, Query and QueryRow methods (and their equivalent Context variants). Positional, named and numbered parameters are supported.
Using context
The standard API supports the same ability to pass deadlines, cancellation signals, and other request-scoped values via the context as the ClickHouse API. Unlike the ClickHouse API, this is achieved by usingContext variants of the methods i.e. methods such as Exec, which use the background context by default, have a variant ExecContext to which a context can be passed as the first parameter. This allows a context to be passed at any stage of an application flow. For example, you can pass a context when establishing a connection via ConnContext or when requesting a query row via QueryRowContext. Examples of all available methods are shown below.
For more detail on using the context to pass deadlines, cancellation signals, query ids, quota keys and connection settings see Using Context for the ClickHouse API.
Dynamic scanning
Similar to the ClickHouse API, column type information is available to allow you to create runtime instances of correctly typed variables which can be passed to Scan. This allows columns to be read where the type isn’t known.External tables
External tables allow the client to send data to ClickHouse, with aSELECT query. This data is put in a temporary table and can be used in the query itself for evaluation.
To send external data to the client with a query, the user must build an external table via ext.NewTable before passing this via the context.
Open telemetry
ClickHouse supports trace context propagation on both TCP and HTTP transports. Useclickhouse.WithSpan to attach a span to a query via the context.
HTTP transport limitationWhile ClickHouse server accepts the standard
traceparent / tracestate HTTP headers, the clickhouse-go HTTP transport does not currently send them — WithSpan has no effect over HTTP. As a workaround, you can set the header manually via HttpHeaders in the connection options.Compression
The standard API supports the same compression algorithms as native ClickHouse API i.e.lz4 and zstd compression at a block level. In addition, gzip, deflate and br compression are supported for HTTP connections. If any of these are enabled, compression is performed on blocks during insertion and for query responses. Other requests e.g. pings or query requests, will remain uncompressed. This is consistent with lz4 and zstd options.
If using the OpenDB method to establish a connection, a Compression configuration can be passed. This includes the ability to specify the compression level (see below). If connecting via sql.Open with DSN, utilize the parameter compress. This can either be a specific compression algorithm i.e. gzip, deflate, br, zstd or lz4 or a boolean flag. If set to true, lz4 will be used. The default is none i.e. compression disabled.
gzip--2(Best Speed) to9(Best Compression)deflate--2(Best Speed) to9(Best Compression)br-0(Best Speed) to11(Best Compression)zstd,lz4- ignored