Crate Pdo Laravel Package

Product Decisions This Supports

• Build vs. buy for the analytics data path. This package is the cheapest way to put a distributed SQL store (CrateDB) behind an existing PHP codebase. It replaces a bespoke CrateDB HTTP client with a standard PDO interface, so the "build" option shrinks to a thin repository layer rather than a protocol implementation. Apache-2.0 means no licensing conversation.
• Storage-engine choice for high-volume, append-heavy features. CrateDB's strengths (time-series, IoT telemetry, log/event data, geospatial and full-text queries at scale) map directly onto feature decisions like "do we build the activity feed / telemetry dashboard / search-heavy reporting screen on our OLTP database, or on a dedicated store?" This driver is the enabling dependency for the second option.
• Read-path architecture and CQRS-lite roadmaps. Because PDO is a low-level primitive, it supports a decision to route writes to MySQL/Postgres and analytical reads to CrateDB, without adding a second language or service runtime to the team's scope.
• Feature scoping for reporting and dashboards. Aggregation-heavy, read-mostly surfaces (rollups, time-bucketed charts, geo filters) are the concrete use cases this unlocks. If those features are on the roadmap, this package is a credible prerequisite; if they aren't, it's not.
• Team-skills investment. Adopting it signals "we will write raw SQL against CrateDB," which is a hiring/training decision as much as a technical one.

When to Consider This Package

Adopt when all of the following hold:

• CrateDB is already chosen or is a serious finalist for a specific workload (telemetry, events, geospatial, full-text) rather than as a general-purpose primary database.
• The application is PHP and you want to stay inside the PDO abstraction — connection handling, parameter binding, and driver-level consistency with the rest of the stack.
• The workload is append-heavy and read-mostly: inserts and aggregations dominate, and multi-statement transactional integrity is not a requirement.
• You are willing to write and own raw SQL (query builder at best), and to wrap the driver behind a repository/gateway interface.

Look elsewhere — or push back — when:

• You expect Eloquent. This is a PDO driver, not a Laravel package: no service provider, no CrateDB connection resolver, no migrations, no model relations, no schema builder. Expect glue code and a maintenance owner.
• CrateDB is not in the stack. The package has no value outside that database.
• You need OLTP semantics. No foreign keys, no meaningful cross-statement transactions, no INSERT ... ON CONFLICT-style patterns the app may assume. Keep the transactional core on Postgres/MySQL.
• You can use the Postgres wire protocol instead. CrateDB speaks the PostgreSQL protocol; pdo_pgsql with Laravel's stock pgsql driver covers many read paths with zero new dependencies. Reserve this package for CrateDB-specific type/param handling that the generic driver mangles.
• Supply-chain risk tolerance is low. ~35 stars and a single-maintainer profile is a real bus-factor concern. Treat it as a pinned, vendored dependency with an exit plan (dropping to a raw HTTP client), not as a foundation.
• A mature alternative exists for the same job — ClickHouse or TimescaleDB have larger PHP ecosystems; if the workload doesn't specifically need CrateDB's feature mix, the ecosystem maturity may win.

How to Pitch It (Stakeholders)

To executives: This is a small, free (Apache-2.0), low-surface-area dependency that lets our existing PHP team put a horizontally scalable SQL database behind our analytics and telemetry features without adding a new language, service, or vendor contract. The strategic value is optionality: it de-risks the "our primary database can't handle these queries" scenario at near-zero cost, and it's removable — it sits behind a single interface, so reversing the decision is an engineering task, not a re-platforming project. The caveat to state plainly: it is a thin, low-adoption open-source driver, so we should plan to own a fork or an exit path, and we should not build transactional business logic on CrateDB.

To engineering: Standard PDO, so connection and parameter handling match the rest of the stack — but understand the boundary. No Eloquent, no migrations, no relations, no schema builder, limited transactional semantics. Write raw SQL, wrap it in repositories, pin the version, and keep a fallback to the Postgres wire protocol or a direct HTTP client. It is a driver, not a framework integration; budget the glue accordingly.