Running ClickHouse in Docker with prorm

Read this page in the documentation

Running ClickHouse in Docker with prorm ClickHouse is a column-oriented OLAP engine. prorm talks to it over the HTTP interface, so there is no native driver to compile. Start the container Port 8123 is the HTTP interface prorm uses; 9000 is the native protocol, useful for clickhouse-client. The repository's compose file defines the same service: Waiting for readiness /ping returns Ok. once the server can serve queries. Connect prorm to it A worked example What ClickHouse does differently It is an analytical store, and the differences bite if you treat it like PostgreSQL: No transactions. db.transaction() has nothing to map onto. No enforced primary keys or unique constraints. The "primary key" is a sorting key; duplicates are allowed and it is on you to avoid them. UPDATE/DELETE are mutations — asynchronous, expensive, and not intended for row-at-a-time work. Model your data as append-only. Partial indexes are unsupported, so a where on an index definition is rejected rather than silently ignored (a bug fixed in 2.0.0). Design for bulk inserts and aggregate reads. See the dialect page for engine selection (MergeTree and friends) and the aggregate helpers. Tear down Troubleshooting Symptom | Cause | --- | --- | Authentication failed | The env vars seed the server only on a fresh volume. | Table already exists after sync({ force: true }) | Drops are asynchronous; give it a moment or use a distinct database per run. | Row missing right after insert | Inserts are visible quickly but not synchronously across replicas — single-node dev should be immediate; check you queried the same database. | Memory limit exceeded | A query exceeded maxmemoryusage. Aggregate more aggressively or raise the limit. | Related reading ClickHouse dialect Query optimization