Filebase Laravel Package

Product Decisions This Supports

• Fast prototyping and MVP delivery: Use it to validate features that need simple persistence without provisioning a database, migrations, or infrastructure. Good for demos, internal tools, and early customer pilots.
• Build vs. buy for lightweight storage: The package replaces a small custom JSON/file-store wrapper. Because it is MIT-licensed and small in scope, it can be vendored or forked if the API fits. The archived status means “buy” is really “adopt with an exit plan,” not “bet the roadmap on it.”
• Ancillary feature storage: Suitable for non-critical data such as app settings, feature flags, small lookup tables, localized strings, import/export staging, test fixtures, and CLI-generated reports.
• Roadmap scoping: Helps teams avoid standing up a full database for peripheral features where SQLite, Redis, or the Laravel cache would be overkill or add ops burden. It also clarifies which features must remain on a transactional database.
• Use cases to prioritize: Single-server apps, low-write admin panels, package prototypes, proof-of-concepts, and internal automations where human-readable JSON files are an advantage.
• Use cases to explicitly reject: Core transactional workflows, multi-tenant billing, inventory, permissions, audit/compliance records, multi-server deployments, and anything requiring concurrent writes, complex queries, or durable recovery guarantees.

When to Consider This Package

Consider it when all of the following are true:

• The data set is small and bounded—typically kilobytes to a few megabytes, not gigabytes.
• Writes are infrequent or can be serialized; concurrent write volume is low.
• The app runs on a single server or in an environment where shared file access is controlled.
• The team values zero-config, human-readable JSON storage and can tolerate file-level backup/restore.
• The feature is non-critical or has a clear migration path to SQLite/MySQL/Postgres/Redis.
• Engineering is willing to vendor/fork the code or accept the risk of an archived dependency last released in 2019.
• PHP/runtime compatibility has been verified for the target Laravel/PHP version.

Look elsewhere when:

• You need transactions, row-level locking, indexes, complex queries, or referential integrity.
• The app is horizontally scaled, containerized with ephemeral storage, or deployed across multiple nodes.
• The data is regulated, customer-critical, financial, or security-sensitive.
• You need active maintenance, security patches, modern PHP support, or a supported Laravel integration.
• Write throughput or data size is expected to grow unpredictably.
• A managed database, SQLite, Redis, or Laravel’s cache/filesystem abstractions already cover the need with less risk.

How to Pitch It (Stakeholders)

Executive summary: tmarois/filebase is a small MIT-licensed flat-file storage package that can accelerate prototypes and peripheral features by removing database setup. It is inexpensive to trial and easy to replace, but it is archived, last released in 2019, and not appropriate as a system of record. Recommend using it only for low-risk, single-server, small-data use cases with an explicit migration plan.

For engineering: The value is simplicity: JSON-backed storage, no migrations, no database service, and a small API surface. The cost is operational and maintenance risk: archived code, uncertain PHP/Laravel compatibility, limited concurrency handling, and no security patching. Treat it as a vendored utility, isolate it behind an interface, add file locking/backup strategy if writes occur, and document the exit path to SQLite or the primary database.

Decision ask: Approve a time-boxed pilot for non-critical storage only—not core product data—with a written fallback plan and compatibility check before adoption.