Turso Client Http Laravel Package

Product Decisions This Supports

• Database selection — Turso/libSQL vs. a conventional managed Postgres. This package is the enabling artifact for the "we can run SQLite-in-the-cloud from plain PHP" option. If a Turso pilot succeeds, it removes the usual objection ("our stack can't talk to Turso without native extensions"), which makes Turso a credible candidate for read-heavy, multi-region, cost-sensitive workloads rather than a toy.
• Deployment topology and the "deploy anywhere" roadmap. HTTP as the transport means no persistent TCP connections and no PECL/native extension in the runtime image. That directly unblocks hosting Laravel on serverless/edge or constrained PaaS targets, and it simplifies CI images and container builds (fewer moving parts, smaller attack surface). This is an infrastructure-optionality decision, not just a library choice.
• Build vs. buy on the data-access layer. The alternative is writing and maintaining our own Turso HTTP wrapper. A thin MIT client is usually cheaper to adopt and vendor than to build — but only if it covers our query/transaction patterns. Decide "adopt / vendor / build" explicitly; the package is small enough that vendoring or forking is a realistic fallback, which lowers the cost of being wrong.
• Feature bets this unlocks or de-risks. Per-tenant database isolation (one Turso DB per customer) without provisioning a fleet of Postgres instances; ephemeral preview environments cloned from a snapshot; cheap read replicas near users; configuration/feature-flag or catalog read stores that don't deserve a full RDBMS. Each of these is a roadmap item whose feasibility answer changes from "no" to "spike it" if this client works for us.
• Cost and ops model. Edge-replicated SQLite can materially change the unit economics and the on-call story versus a single-region Postgres cluster. Treat the package as the cheapest possible experiment to price that shift before committing a quarter of engineering to it.

When to Consider This Package

Consider it when:

• Turso/libSQL is already on the table, or you want a cheap way to put it on the table without committing.
• Your runtime can't install the libSQL PHP extension — serverless functions, locked-down PaaS, shared hosting, slim production images.
• You want a small, permissively licensed (MIT), low-magic dependency rather than a framework-shaped abstraction.
• Your access pattern is mostly reads, short queries, and modest write volume — the profile where per-request HTTP overhead is tolerable.
• You're prototyping or building an internal tool where a single-maintainer library is an acceptable risk.

Look elsewhere when:

• Performance is the point. Every query pays an HTTP round-trip; long transactions, bulk loads, and chatty ORM access patterns will suffer relative to a socket-based driver. Benchmark against your real query mix, not a SELECT 1.
• You need the full libSQL surface — interactive/long-lived transactions, embedded replicas, or features the HTTP API doesn't expose. Confirm parity before you design around them.
• You need vendor support, an SLA, or a large maintainer community. 49 stars and a single maintainer is the headline risk; treat it as "small OSS with a bus factor of one," not "infrastructure."
• Eloquent/query-builder integration is a hard requirement. Gating question: does this package ship a Laravel database connector/DBAL driver, or is it a raw HTTP client you'd wrap yourself? If it's raw, budget for the adapter and for losing ORM conveniences (migrations, relationship loading, pagination) unless you build them.
• Your existing stack already has a first-party or well-supported path (official libSQL clients, PDO-based drivers, or a different database entirely). Don't add a bespoke transport to save a dependency.

Validate before adopting: PHP/Laravel version support, test coverage, release cadence, whether Turso's HTTP API version it targets is stable, and whether failures are surfaced as typed exceptions you can retry on.

How to Pitch It (Stakeholders)

For executives (the 30-second version): We're evaluating Turso — a managed, globally replicated SQLite database — as a cheaper and simpler alternative to our current database for a subset of workloads. This package is the small, free (MIT) PHP client that lets our app talk to it without changing our hosting constraints. It costs us a spike, not a migration, to find out whether the economics work.

For engineering (the honest version): It's a thin HTTP client for Turso's API. Strengths: no native extension, works in serverless/containerized runtimes, tiny surface area, MIT so we can fork or vendor. Weaknesses: HTTP-per-query latency, limited transaction semantics versus a socket driver, and a single-maintainer project with low adoption.

Recommended posture — adopt behind a seam:

1. Define a narrow interface in our codebase (a repository/gateway) and put this client behind it. Swapping to the official libSQL client or back to Postgres then becomes a contained change, not a rewrite.
2. Pin the version and vendor the dependency; assume maintenance may fall to us.
3. Time-box a spike against a representative query mix with real latency and failure-mode numbers.
4. Decide on evidence: if the spike shows acceptable p95 latency and the API covers our transaction needs, proceed; if not, we've spent days, not a quarter.

What I'm not claiming: that this package is production-hardened, or that Turso is the right database for our primary write path. The pitch is optionality at low cost — a bounded experiment that tells us whether a meaningfully cheaper deployment model is available to us.