Phpclickhouse Laravel Laravel Package

Product Decisions This Supports

• Build vs. buy for analytics/OLAP features: This package lets a Laravel team use ClickHouse (a columnar OLAP database) through native Laravel idioms — Eloquent-style models, migrations, schema builder, Artisan generators — instead of building a custom data-access layer or bolting on a separate service. That directly informs whether to standardize analytics workloads on ClickHouse vs. a managed warehouse.
• Roadmap sequencing for analytics/eventing features: Teams can now scaffold ClickHouse models and migrations with make:clickhouse-model and make:clickhouse-migration, which shortens the path from "we want product analytics / event tracking / large-scale reporting" to a working schema. This supports committing to analytics-heavy roadmap items with less upfront engineering risk.
• Developer-experience and CI investment: The bulk of v4.2.0 is PHPStan extension work (typed migrations, nullable handling for read-only connections, MATERIALIZED/ALIAS columns, parallel query typing, disabling Larastan's migration cache). This lowers the cost of enforcing static analysis on analytics code — a meaningful signal when deciding whether to mandate PHPStan across the codebase.
• Operational topology decisions: Read-only-connection awareness in the type system supports decisions about primary/replica and read-only ClickHouse topologies without sacrificing type safety.
• Upgrade/migration planning: The lc-upgrade-3x-to-4x refinement (only suggesting schema:dump for tables no migration creates) reduces friction in 3.x→4.x upgrades, informing timing of a framework/database modernization initiative.
• Use cases this unlocks: product/behavioral analytics, event ingestion, large-scale reporting and dashboards, log/telemetry storage, and any workload where row-oriented relational tables are becoming a bottleneck.

When to Consider This Package

Consider adopting when:

• You are on Laravel/PHP and need an OLAP store for high-volume event, analytics, or reporting data, and want it to feel like native Eloquent rather than a separate stack.
• Your team already uses (or plans to use) PHPStan/Larastan and values static analysis on schema and query code — v4.2.0's extension work is specifically aimed at this.
• You need ClickHouse schema managed through versioned migrations and Artisan tooling rather than hand-run DDL.
• You are upgrading from 3.x and want guided migration into 4.x.
• You want read-only/replica connection setups reflected correctly in your type system.

Look elsewhere when:

• You need a mature, widely adopted ORM with a large ecosystem of third-party integrations — this is a narrower, community package with a smaller surface area and fewer maintainers.
• Your team does not use PHPStan; a large share of this release's value is tooling you would not consume.
• You require vendor-backed support/SLAs, or your analytics needs are better served by a managed warehouse plus a dedicated ingestion pipeline.
• Your workloads are transactional/OLTP rather than analytical — ClickHouse is the wrong engine regardless of the package.
• You cannot tolerate API churn: this release deprecates PHPStan\ConnectionConfig::isReadOnly() in favor of hasReadOnlyClickHouseConnection(); teams sensitive to deprecation cycles should weigh that.

How to Pitch It (Stakeholders)

For executives: This release is a maturity milestone for our ClickHouse-on-Laravel integration. It does not change the product surface we ship to customers; it reduces engineering risk and cost in our analytics stack. Concretely, it (1) adds Artisan generators so engineers scaffold ClickHouse models and migrations in minutes instead of hand-writing schema, (2) substantially strengthens static analysis so analytics code is checked in CI like the rest of our codebase, and (3) smooths the 3.x-to-4.x upgrade path. Net effect: faster delivery of analytics/reporting features, fewer production schema surprises, and lower long-term maintenance burden. There is one internal deprecation (isReadOnly() → hasReadOnlyClickHouseConnection()) that affects our own tooling only, not customers.

For engineering: v4.2.0 is primarily a developer-experience release for the PHPStan extension. Highlights: migrations and ClickHouse column types are now understood by static analysis; Float32/Float64 and MATERIALIZED/ALIAS columns are correctly typed as nullable (including read-only-connection awareness); Larastan's migration cache is disabled to avoid stale-type false positives; Parallel::get()/getRows() accept any model's query; and new SchemaDropCommand/SchemaIndexDefinition classes make drop()->sync() and index()->granularity() type-safe. New make:clickhouse-model and make:clickhouse-migration commands bring schema authoring in line with standard Laravel workflows. Action items: migrate off the deprecated ConnectionConfig::isReadOnly(), re-run PHPStan after upgrading, and review the refined lc-upgrade-3x-to-4x guidance if mid-upgrade. No breaking changes in this release.