- How do I install glushkovds/clickhouse-builder in a Laravel app?
- Install it with Composer using composer require glushkovds/clickhouse-builder, then publish the package config and let Laravel's package discovery register the service provider and facade. The integration surface is deliberately small: a provider, a facade, and a config block for your ClickHouse connection. Because of that, you can contain the whole package inside a single adapter class in your application. Total wiring effort is low, and so is the blast radius if you later swap it out.
- Is clickhouse-builder an Eloquent ORM for ClickHouse?
- No. It is a query-construction layer, not a full ORM or connection manager, so there are no models, relationships, or model events. The fluent API intentionally mirrors Laravel's DB::table() idiom, which means near-zero cognitive adoption cost for a team already writing query-builder code. That scope is a good match for ClickHouse, which is typically used as an append-only analytics sink rather than a transactional store.
- Can I use this ClickHouse builder alongside MySQL or Postgres in the same Laravel app?
- Yes, that is the intended pattern: keep MySQL or Postgres for OLTP and point ClickHouse at your read path and bulk appends. The builder is a separate connection layer, so it does not interfere with your existing Eloquent connections. It is a poor fit for anything transactional or requiring relational integrity, which is correct behaviour for ClickHouse anyway. Wrap the ClickHouse calls in a dedicated service or gateway class so the two data paths stay independent.
- Does clickhouse-builder bind parameters safely, or does it interpolate values into SQL?
- This must be proven in a spike, not assumed. A string-building fluent layer is a classic SQL injection footgun, so test with hostile values before trusting it in production. Confirm whether the values you pass to where() and similar methods are sent as bound parameters or concatenated into the final SQL string. Also verify HTTP interface authentication and TLS handling if that is your transport. Treat parameter binding as a hard adoption gate.
- Can I create tables or run migrations with this package?
- There is no evidence of a schema builder or migration system in the package, so DDL will be raw SQL managed outside of it. That is acceptable for ClickHouse, but it means schema ownership sits with your team rather than in Laravel migrations. Keep your table definitions in versioned SQL files or a separate deployment step. Do not expect the fluent API to handle ALTER or CREATE statements for you.
- Is glushkovds/clickhouse-builder production ready given its low star count?
- Adoption risk is the headline concern: roughly two stars, zero dependents, and effectively a single maintainer means there is no external validation of production use. The positive signal is a recent release dated 2026-04-19, which suggests the maintainer is active and lowers near-term abandonment probability. Recency does not offset the lack of adoption, so run a timeboxed spike against a containerized ClickHouse first. Verify the transport (HTTP versus native TCP), whether connections are reused or created per query, and the timeout, retry, and error-classification behaviour on failure.
- Does it support ClickHouse-specific clauses like FINAL, PREWHERE, SETTINGS, and arrayJoin?
- The package advertises support for ClickHouse-specific clauses, expressions, and database operations beyond standard SQL, which is the main reason to use it over a generic query builder. Still, verify each feature your queries depend on in a spike rather than trusting the README. ClickHouse moves quickly, and small packages tend to fall behind on newer capabilities such as async_insert, lightweight deletes, and settings profiles. Pin a version you have tested and re-run your query suite before upgrading.
- How do I handle inserts and bulk writes with this ClickHouse builder?
- Bulk append writes are one of the two intended use cases, alongside dashboard and aggregation reads. Confirm in your spike whether the insert path is single-row, batched, or uses async_insert, and whether any deduplication support exists. Error classification matters here too, because a failed batch should be retryable without duplicating rows. Validate both raw type fidelity and null/final value handling before shipping.
- Which Laravel and PHP versions does it support, and is Lumen really supported?
- The package states integration with both Laravel and Lumen through a service provider, facade, and config block. Lumen bootstrapping differs from Laravel, so confirm genuine support instead of assuming it from the description. For a modern stack you should target PHP 8.x with Laravel 10 or 11 and check which combinations are exercised in CI. If there are no integration tests against a real ClickHouse server, write your own smoke test.
- What should I do if the package is abandoned, and are there alternatives?
- Because it is a thin fluent wrapper, forking or vendoring it is realistic if the maintainer walks away. Keep the fluent API behind an internal interface such as AnalyticsQueryGateway so callers see intent-shaped methods rather than builder chains, making replacement a one-class change. Pin exact versions and review lockfile diffs, since a low-scrutiny supply chain deserves that discipline. The opportunity score of 60.14 signals a genuine market gap for a well-maintained Laravel ClickHouse client, so an exit ramp is worth more than deep coupling.