Kurrentdb Core Laravel Package

Technical Evaluation

Architecture fit. kurrentdb-core is a thin, transport-level client for the KurrentDB (formerly EventStoreDB) HTTP API — not an ORM, not a Laravel package, not an abstraction layer. It fits cleanly into a hexagonal/ports-and-adapters architecture as an infrastructure adapter at the persistence edge: your domain repositories define append/read semantics, and this package implements them against KurrentDB. It only makes architectural sense if the product is genuinely committed to event sourcing or CQRS with an append-only log as the system of record. If the need is "we want an audit trail" or "we want to store events somewhere," a relational outbox table plus a queue is almost always the cheaper, lower-risk answer. The absence of a framework opinion is a feature for portability but means the Laravel-shaped work is yours to build.

Integration feasibility. Integration is a config-and-wiring exercise, not a deep refactor. Realistically a TPM should plan for a PSR-18/PSR-7 HTTP client dependency (Guzzle or Symfony HttpClient), a container binding, and a small config block for endpoint, credentials, and TLS. Expect to write the Laravel service provider and facade yourself unless a companion *-laravel package exists — the "core" naming strongly implies a split package strategy, so verify before scoping. A day or two gets a working proof of concept that appends to and reads from a stream.

Technical risk. The dominant risks are maturity and support, not the code itself — 69 stars and 0 dependents means essentially no downstream validation in the wild. Secondary risks:

• HTTP API surface ceiling. The KurrentDB HTTP API is narrower than gRPC. Subscriptions, persistent subscriptions, and some projection management are typically gRPC-first; confirm the read/write coverage you need exists over HTTP before designing around it.
• Concurrency and idempotency. Correct use of expected-revision semantics is on you; a naive adapter will silently produce duplicate or lost-write behavior under retries.
• Release metadata. A "last release" dated 2026-07-02 in the future warrants sanity-checking — pinning should be based on verified tags, not the reported date.
• Single-maintainer bus factor. MIT licensing mitigates this to "we can fork," but only if someone on your team can own PHP HTTP client code.

Key questions.

1. Does a companion Laravel integration package exist, or is this the whole story?
2. Does the HTTP API (and this client's coverage of it) support the subscription model the design requires, or do we need a gRPC client?
3. What are the PHP version, PSR interface, and HTTP client constraints?
4. Is there a test suite, and does it run against a live KurrentDB instance or mocks only?
5. Who maintains it, what is the release policy, and is there a fork plan on the shelf?
6. What is the auth model (basic, TLS, tokens) and how are credentials managed?

Integration Approach

Stack fit. PHP 8.x + Laravel, KurrentDB as a standalone event store or cluster. The client is stateless and transport-agnostic, so it drops into existing DI and config conventions with minimal friction. It has no opinion on queueing, transactions, or framework lifecycle — that's deliberate and appropriate for a core library.

Migration path. Do not attempt a big-bang migration off the existing database. Event sourcing is additive: stand KurrentDB up alongside the current store, introduce it for a single bounded context, and keep the existing relational database as the read model. Where the current system needs to stay authoritative during transition, use a transactional outbox or dual-write with a reconciliation job rather than trying to make two stores transactional. Retire the old write path only once projections and replay have been proven in production.

Compatibility. Pin the exact tag; verify PHP constraints, PSR-7/PSR-18 versions, and whether the HTTP client is injected or hardcoded. Lock the KurrentDB server version to match the API surface the client was written against, and add contract tests that hit a real containerized instance so a server upgrade fails loudly rather than at runtime. Treat any future client release as a breaking-change candidate until proven otherwise.

Sequencing.

1. Spike (1 week): containerize KurrentDB, append/read a stream, validate subscriptions and expected-revision behavior through the client.
2. Adapter (1–2 weeks): wrap the client behind domain-owned interfaces; hide the package types from application code entirely.
3. Contract tests + CI: run against a real KurrentDB instance in the pipeline.
4. One bounded context in production with observable replay and projection rebuild drills.
5. Expand only on evidence — no further contexts until operational confidence exists.

Operational Impact

Maintenance. This is the crux. Low stars, zero dependents, and a single maintainer mean you should onboard it as if it were vendored code: pin the version, keep a fork in your own org namespace, and confirm someone can patch it. MIT licensing makes forking legally trivial, which converts "abandoned project" from a crisis into a maintenance task. Budget a small but recurring allowance for upstream tracking; do not assume timely security or bug fixes.

Support. Community-only, no SLA, no vendor relationship. Escalation path is "we fix it." The KurrentDB server side is the more mature dependency; lean on its documentation for operational questions and treat the PHP client as replaceable glue.

Scaling. The client itself is near-free to scale — it is stateless and adds only an HTTP hop. Real scaling levers are connection reuse and pooling, batching appends where the API permits, and keeping payloads small. Throughput ceilings will be dominated by KurrentDB cluster topology, stream partitioning, and read-model projection lag, not by this package. Watch for per-request overhead in hot write paths and measure before optimizing.

Failure modes.

• Transient network failures on append — must be retried with the same expected revision to avoid duplicate events.
• Concurrency conflicts surfaced as version-mismatch errors — your adapter must map these to domain-meaningful outcomes, not generic exceptions.
• Eventual consistency between the event log and read models — user-facing behavior must tolerate projection lag.
• Serialization drift — schema evolution of stored event payloads is a long-term operational commitment; plan versioning from day one.
• Server/client version skew — silent contract breakage on upgrade; contract tests are the control.
• Credential and TLS misconfiguration — verify at boot with a health check rather than discovering it on the first write.

Ramp-up. Learning the library is measured in hours; learning to operate event sourcing is measured in weeks to months. The team needs competency in stream design, event versioning, projection rebuilds, and KurrentDB cluster operations — none of which this package provides or abstracts. Plan for a senior engineer with event-sourcing experience to own the pattern, and treat the client as the least interesting part of the integration. If that expertise does not exist internally, the honest recommendation is to defer adoption rather than absorb the pattern risk alongside the package risk.