- How do I install and configure kitar/laravel-dynamodb in a Laravel app?
- Install it with Composer and configure it as another Laravel database connection using the dynamodb driver. You will need the AWS SDK for PHP and appropriate IAM credentials for DynamoDB access. The package is MIT-licensed and designed for low-ceremony setup alongside your existing Laravel connections.
- Which Laravel and PHP versions does kitar/laravel-dynamodb support?
- The package is positioned to complement Laravel 10, 11, and 12 with PHP 8.1 and above. Its release cadence tracks framework versions, but you should confirm the exact compatibility matrix for your pinned Laravel minor in CI. Do not rely on community consensus alone; verify behavior against your application version.
- Can I test kitar/laravel-dynamodb locally without hitting AWS?
- Yes, the package includes local DynamoDB support for development and testing. Run unit and integration suites against DynamoDB Local to avoid AWS spend and flakiness. A thin repository interface around the package can also make tests easier to isolate and swap.
- Is kitar/laravel-dynamodb a drop-in replacement for Eloquent models backed by MySQL or Postgres?
- No. The package provides an Eloquent-flavored facade over DynamoDB, but DynamoDB is a key-value and document store, so the Eloquent mental model does not map cleanly to joins, ad-hoc where clauses, migrations, and auto-incrementing IDs. Eloquent parity is partial, with likely gaps in joins, eager loading semantics, aggregates, and mass-assignment or event behavior. Use it for a bounded context with known access patterns, not as a drop-in replacement for existing relational models.
- What DynamoDB features does kitar/laravel-dynamodb support, such as single-table design, GSIs, and condition expressions?
- The package supports single-table design with partition and sort keys, GSIs and LSIs, and condition expressions such as attribute_exists and begins_with. It also provides relationship traversal helpers, so it can model real DynamoDB constructs rather than only toy examples. These features are enough to implement common bounded-context use cases like session stores, audit feeds, and per-tenant aggregates.
- How do I avoid expensive scans when using the Laravel DynamoDB query builder?
- Treat abstraction leakage as a high risk: query-builder ergonomics can encourage patterns DynamoDB penalizes, and a misused where clause can degrade into a Scan that is slow and expensive at scale. Enumerate your access patterns before writing model code and enforce guardrails through code review. Design keys and indexes around those patterns rather than relying on ad-hoc querying.
- Does kitar/laravel-dynamodb support DynamoDB transactions and conditional writes?
- The package supports condition expressions such as attribute_exists and begins_with, which are useful for conditional write paths. DynamoDB transactions have a 100-item cap, and the assessment flags transaction support and conditional writes as key questions to resolve for your write paths. Verify transaction API coverage against the package documentation and your pinned version before relying on it in production.
- How should I handle schema, tables, and GSIs with Laravel migrations when using DynamoDB?
- DynamoDB does not use traditional Laravel migrations. Provision tables, GSIs, LSIs, and capacity mode through infrastructure as code such as CDK, Terraform, or CloudFormation, and treat the table definition as infrastructure rather than application code. A relational-to-DynamoDB backfill should be a one-off job with careful key design, idempotency, and an explicit dual-write cutover window.
- What consistency and production concerns should I consider before using DynamoDB with Laravel?
- GSI reads are eventually consistent by default, so opt into strongly consistent reads where the user experience demands it. The Eloquent-style abstraction can mask DynamoDB cost and latency characteristics, so monitor access patterns and avoid accidental scans. Also plan for IAM credentials, a small contributor base, and a fork-or-vendor contingency for this production dependency.
- Is kitar/laravel-dynamodb actively maintained, and what are the alternatives?
- It has around 193 stars and a June 2025 release, indicating active but niche maintenance well below the adoption of first-party MySQL and Postgres drivers. The contributor base is small, so a fork-or-vendor contingency is prudent if you depend on it in production. If you need ad-hoc querying, BI access, or tighter control, using the AWS SDK directly or keeping a relational store may be a better fit than this abstraction.