Weave Code
Db Tools Bundle Laravel Package
makinacorpus/db-tools-bundle
Symfony bundle for database maintenance: create and restore backups, anonymize sensitive data, and run SQL commands through configurable, Doctrine-friendly console tooling for safer development and production workflows.
A PHP library to back up, restore and anonymize databases
Frequently asked questions about Db Tools Bundle
- Is makinacorpus/db-tools-bundle compatible with Laravel?
- No, not natively. Despite being catalogued alongside PHP libraries, it is a Symfony bundle built on the Symfony DI container, Symfony Console commands and Doctrine ORM/DBAL metadata. Laravel's service container, Artisan and Eloquent are structurally different, so there is no drop-in integration path. In a Laravel context it is best treated as an external ops tool or as a source of ideas to reimplement.
- Can I just run composer require makinacorpus/db-tools-bundle in a Laravel app?
- You can install the code, but you cannot use it meaningfully without a Symfony kernel. The bundle registers services and console commands through Symfony's bundle and DI conventions, and the anonymization layer reads Doctrine entity metadata. Without those pieces the commands have nothing to bootstrap against. Realistically you need either a separate Symfony application or a reimplementation on Laravel's schema and query builder.
- Which Symfony and PHP versions does release 2.2.0 support?
- Release 2.2.0 adds Symfony 8 support, which targets a modern PHP runtime of roughly 8.4 and above. Whether the 2.2.0 support matrix still includes Symfony 6.4 LTS and 7.x branches should be verified against the actual composer.json, because the release notes mention only the new feature. This matters practically: if you plan a sidecar Symfony CLI, its PHP floor must be at least as new as your Laravel app's runtime. Pin the branch you need rather than trusting release metadata alone.
- Can I run it as a standalone Symfony sidecar CLI against my Laravel database?
- Yes, this is the more realistic integration path. You deploy a small Symfony application containing the bundle, point it at the same database your Laravel app uses, and trigger db-tools:backup, db-tools:restore or db-tools:anonymize from Laravel's scheduler, a deploy hook or CI. It is not a framework-free CLI, so you maintain a second runtime and its dependency tree. The upside is that the package is actively tracking current Symfony majors, so the sidecar is unlikely to be stranded on an unsupported branch.
- Are the backup and restore commands safe to run against a production database?
- Treat restore as destructive and high impact. The bundle is a thin utility layer, and nothing in the documented feature set guarantees dry-run modes, confirmation gates or transactional handling. Before pointing it at anything valuable, verify behaviour in staging, confirm dump integrity and test the restore path end to end. For production, wrap invocations in your own confirmation and backup-before-restore safeguards.
- How does data anonymization work and what are the GDPR risks?
- Anonymization is driven by Doctrine ORM/DBAL metadata: you declare strategies per entity attribute using Doctrine types and attribute configuration, and the bundle transforms values during dump or export. Coverage is only as good as your configuration, so any PII column you forget is exported in clear text into non-production environments. The release line does not add coverage verification, dry-run reporting or leak detection, so build your own column audit and review process if this feeds GDPR-scoped data.
- Can I drive anonymization rules from Eloquent models instead of Doctrine attributes?
- Not out of the box. The strategy catalog is expressed through Doctrine metadata, and no framework-agnostic extract has been published, so Eloquent casts and schema introspection are not consumed directly. The workable approach is to read the strategy semantics and reimplement them on top of Laravel's schema builder plus a faker or format-preserving library. Plan for consistent, foreign-key-aware pseudonymization yourself, since that is where naive implementations usually break referential integrity.
- Which database engines and versions are supported?
- Support flows through Doctrine DBAL, so MySQL/MariaDB, PostgreSQL and SQLite are the expected targets, but the tested matrix is not stated in the package description. Managed services such as RDS, Aurora or Cloud SQL introduce their own auth, TLS and permission constraints that need explicit validation. Check the repository's CI matrix before committing, and run a restore rehearsal against an equivalent instance rather than assuming parity.
- Is makinacorpus/db-tools-bundle actively maintained, or is it abandoned?
- It is maintained but small. Popularity is low, with a few hundred stars and effectively no dependent packages, and the bus factor is concentrated in Makina Corpus. Release 2.2.0 is direct evidence of ongoing maintenance and reduces, though does not remove, abandonment risk. Weigh that against the cost of vendoring or extracting the parts you rely on, especially for a compliance-sensitive anonymization workflow.
- What Laravel-native alternatives should I compare before adopting it?
- For backups, Laravel-focused packages and plain mysqldump or pg_dump wrappers in a scheduled command cover most needs with less machinery. For anonymization, a custom Artisan command combining schema introspection, Faker and explicit column allowlists gives you Eloquent-aware coverage and testability. Choose the Symfony bundle mainly if you already run Symfony services or want its ready-made strategy catalog and command semantics. Otherwise the build-versus-borrow arithmetic usually favours a small in-app implementation.
Weaver
How can I help you explore Laravel packages today?