- How do I install norbybaru/laravel-aws-timestream in a Laravel application?
- Install it with Composer using composer require norbybaru/laravel-aws-timestream, then register the package service provider if your Laravel version does not auto-discover it. Publish the package configuration file with the vendor:publish command so you can set your Timestream database, table, and region. Credentials are resolved through the standard AWS SDK credential chain rather than being hardcoded in the config. Once published and configured, you can start issuing queries through the DB facade or the provided model.
- Which Laravel and PHP versions does laravel-aws-timestream support?
- The 1.0 release targets Laravel 10, 11, and 12 and drops Laravel 9 support, since Laravel 9 is out of security support. Because the framework drop likely accompanies a PHP floor bump, you should read the require and require-dev blocks in composer.json for the exact PHP and illuminate/* constraints before assuming parity with your other services. There is no supported overlap between 0.4.x and 1.0, so services still on Laravel 9 must stay pinned to 0.4.x until they upgrade.
- How does this package fit into Laravel's database layer?
- It slots a Timestream connection driver into Laravel's existing database layer, so time-series reads and writes can be expressed through the DB facade and fluent query builder instead of a bespoke AWS SDK wrapper in every service. That makes it a low-friction fit for teams already comfortable with Eloquent conventions. If your codebase enforces strict repository or port boundaries, treat the driver as an infrastructure detail and hide it behind your own interface so a future store swap stays contained.
- How are AWS credentials and region configured for Timestream?
- Credentials are resolved through the AWS SDK's default credential chain, so environment variables, shared credential files, and IAM instance or task roles all work as usual. Region and other connection settings live in the publishable package config file. The release notes do not describe whether retry and backoff behaviour is inherited from the AWS SDK or reimplemented by the wrapper, so verify that in the source if your workload is sensitive to throttling.
- Can I use an Eloquent-style model to query and write time-series records?
- Yes, the package provides an Eloquent-style model plus a fluent query builder, which is the main reason to choose it over calling the AWS SDK directly. You get familiar Laravel syntax for writing and querying time-series data rather than hand-building Timestream request payloads. Bear in mind that Timestream is not a relational store, so not every Eloquent feature translates; keep queries close to what the wrapper documents.
- Is norbybaru/laravel-aws-timestream production ready?
- The 1.0.0 tag is the meaningful signal, because the maintainer is now committing to semantic versioning, which is what makes it defensible to depend on in production. However, the package is single-maintainer with a low commit cadence, so treat it as a thin adapter you could reasonably vendor or replace. Pin ^1.0, review the diff between v0.4.0 and v1.0.0 for undocumented changes, and budget for the possibility of forking.
- What is the migration path from 0.4.x to 1.0.0?
- The only documented breaking change is the removal of Laravel 9 support, with no public API changes called out in the release notes. Even so, a 0.x to 1.0 transition should be treated as a major: pin ^1.0, diff the two tags for undocumented signature or config changes, and run your full test suite before promoting. Services that must stay on Laravel 9 have to remain pinned to 0.4.x until the framework upgrade is complete.
- Does the package handle batching, pagination, retries, and partial write failures?
- These behaviours are not described in the release notes, so they are genuine unknowns you should confirm before relying on them. Specifically, check whether the driver exposes WriteRecords batching and whether it surfaces per-record RejectedRecords from partial failures or silently swallows them. Also verify how pagination of query results is handled and whether retry and backoff come from the AWS SDK or are reimplemented. A short non-production spike that ingests a representative metric stream is the quickest way to answer these questions.
- Is AWS Timestream for LiveAnalytics a safe long-term target?
- This is the single biggest adoption risk, and it is independent of the package itself. AWS has signalled a limited roadmap for Timestream for LiveAnalytics and has been steering workloads toward Timestream for InfluxDB and other time-series stores, so validate your decision against the current AWS service lifecycle notice before building on it. Run that lifecycle check as a go/no-go gate before any code work, and wrap the driver behind your own repository interface so a future store swap is contained.
- How should I test and roll out laravel-aws-timestream in a real project?
- Test coverage details are not documented, and it is unclear whether integration tests run against a real Timestream endpoint or only against mocks, so plan to add your own coverage. Do a timeboxed spike in non-production that ingests a representative metric stream and verifies batching, throttling behaviour, and your query patterns. Then pin ^1.0, add the package to your shared CI matrix, and roll out to one non-critical metrics pipeline before expanding. Keep in mind the larastan bump to ^1.0|^2.0|^3.0 is dev-only and matters mainly if you share a PHPStan baseline across packages.