QueryBench

Docs / Database engines

Database engines

Engine-specific behavior for PostgreSQL, MySQL, SQLite, DuckDB, ClickHouse, MongoDB and Redis.

Every engine is a separate Go package behind one common session interface. Capabilities are declared truthfully: optional features are disabled or return explicit unsupported errors until they are implemented and covered by real integration tests.

EngineHighlights
PostgreSQLSchemas, catalog metadata, JSON and JSONB, constraints, sequences, identity and default insertion, transactional staged changes, stored functions, user management.
MySQLDatabase namespaces, quoted identifiers, auto-increment and default insertion, JSON, stored routines. DDL commits separately from row edits. InnoDB required for rollback.
SQLiteLocal files with read-only mode, foreign keys, generated columns, atomic staged changes, VACUUM INTO backups.
DuckDBLocal analytical files with read-only mode, saved macros, native EXPORT DATABASE backups.
ClickHouseNative TCP protocol on port 9000. Synchronous mutations for updates and deletes. Skipping-index management. No transactional rollback.
MongoDBCollections as _id plus highlighted Extended JSON. Native find and aggregate commands. Multi-document batches need a replica set or sharded deployment.
RedisNumbered databases with SCAN pagination, key type, TTL and JSON values. String, hash, list, set, sorted set and stream editing. Native command tabs.

ClickHouse notes

Primary and sort keys are not uniqueness constraints, so edits use complete original values and reject ambiguous matches. Mutations run separately and cannot roll back; completed keys are removed from pending changes after partial success. Updating sorting-key columns may be rejected by the server.

MongoDB notes

Single-document CRUD works on standalone servers. ObjectIDs, dates and large integers retain Extended JSON types. The _id column is read-only; edit the document JSON for insertion. SRV connection strings are not yet exposed in the host and port form.

Redis notes

Replacements are built under temporary keys before a watched transaction replaces the originals, so a validation failure never deletes an existing value. TTL is preserved unless changed. SCAN order is not stable and filtered totals are unknown. Cluster routing is not yet exposed.