Laravel Kvstore Laravel Package

Product Decisions This Supports

• Storing runtime-editable configuration and feature flags without a schema migration. A key-value store lets PMs ship settings (limits, toggles, copy variants) that product/ops can change without engineering deploys — a build-vs-buy win over a bespoke settings table.
• Per-tenant or per-user preferences and lightweight state. Useful for scoping decisions like “which plans get the new dashboard” or “store this user’s last-used filter,” where a full relational model is overkill.
• Safe storage of structured values when the cast is explicit. v2.3.0 makes the data-integrity contract enforceable: arrays, plain objects, and enums must go through a serialising cast (array, json, object, collection) or be serialised by the caller. That supports product decisions to let non-engineers write structured settings through admin tooling without risking silent JSON-string corruption.
• Upgrade / migration planning. The release is a minor, not a patch, because a previously documented limitation (storing an array with no cast and reading back raw JSON) now raises. PMs should budget a short audit of callsites that write arrays/objects/enums without explicit casts before rolling to v2.3.
• Roadmap signal: the maintainers are tightening correctness rather than adding surface area. For a PM, that favours keeping the package for low-risk, low-throughput product config and not stretching it into a general-purpose document store.

When to Consider This Package

Consider adoption when:

• You need simple, database-backed key-value persistence in a Laravel app — app settings, feature flags, tenant preferences, cached computed values — and want a small dependency rather than a bespoke table plus access layer.
• You value explicit type contracts: v2.3.0’s guard rejects writes that would silently degrade (e.g. KvStore::set('features', ['beta' => true]) now throws InvalidArgumentException instead of storing '["a"]' on update or failing with Array to string conversion on insert). For product data, silent degradation is worse than a loud failure.
• Your read path is not latency-critical, or you can layer caching in front of it.
• You can tolerate a minor upgrade with a narrow behavioural change: audit any call that relied on the old “array without cast” limitation, then pass a serialising cast or serialise manually. If you cannot fix those callsites yet, pin to 2.2.

Look elsewhere when:

• You need high-throughput or hot-path reads — use Redis, a dedicated column, or a proper cache.
• You need querying by value, relational integrity, versioning, or audit trails — a KV table is the wrong shape.
• You are storing large blobs or evolving schemas where a cast-only contract is too blunt.
• You need guaranteed backwards compatibility across minor releases and cannot absorb a documented-limitation-turned-exception, even with a clear migration note.

New adopters should treat v2.3.0 as the baseline: the strictness is a feature, and the test suite now pins accepted scalar types (strings, numbers, booleans, null, DateTimeInterface, __toString objects including Collection) so the guard should not quietly narrow later.

How to Pitch It (Stakeholders)

For executives: This is a small, low-risk Laravel package for storing product settings and feature flags in the database. The new release (v2.3.0) fixes a silent data-corruption path: previously, writing an array without the right cast could either crash on insert or silently store a raw JSON string on update, indistinguishable from an intentionally stored value. It now fails fast with a clear error naming the type and the cast that fixes it. That is a maturity improvement, not a feature expansion. The practical cost is a short engineering audit of any code that writes arrays, objects, or enums to the store; the practical benefit is fewer “why did this setting turn into a string?” incidents.

For engineering: v2.3.0 makes set() reject values that a text column cannot accept as-is unless a serialising cast is present. set('features', ['beta' => true]) and set('features', ['beta' => true], 'integer') both throw InvalidArgumentException; set('features', ['beta' => true], 'array') succeeds. Scalars, null, DateTimeInterface, and __toString objects (including Collection) remain unaffected. There are no schema changes and no other API changes. Upgrade path: grep for KvStore::set( calls passing arrays, plain objects, or enums without array/json/object/collection, and either add the cast or serialise before writing. This is a minor because a documented limitation now raises; it is not a supported-behaviour break.