Database driver compatibility checks violate the codebase convention. The repository uses PostgreSQL exclusively and should not include SQLite compatibility layers or driver checks. Remove the conditional logic and use only the PostgreSQL implementation.

Test does not verify that system-created records are actually excluded from activation count. The test creates a user with a SYSTEM-sourced record but only calls assertOk() without checking that this user is NOT counted as activated. Add assertions to verify that the activated user count is 0 since the only record has CreationSource::SYSTEM.

getPeriodDates() sets $previousEnd = $currentStart while the downstream queries use inclusive whereBetween()/BETWEEN. This causes boundary timestamps (exactly at $currentStart) to be counted in both the current and previous period, skewing period-over-period comparisons. Consider switching to half-open intervals (e.g., >= start and < end) or offsetting one of the boundaries (e.g., previous end minus 1 second) so periods don’t overlap.

getData() performs per-interval work that results in multiple heavy queries (union across entity tables + an additional users aggregate) inside the weekly loop. For larger periods (e.g., 365 days) this scales to dozens of union queries and can become slow. Consider computing weekly active creators for the whole period in a single query (e.g., date_trunc('week', created_at) grouped results) and deriving new vs returning counts from that dataset.

The widget pulls all active creator IDs into PHP (DB::select + pluck) and then feeds them into whereIn('id', $activeCreators). With high activity this can create very large parameter lists and extra memory overhead. Prefer keeping this as a subquery/CTE and joining/filtering in SQL rather than materializing IDs in application memory.

This test is named as if it validates new vs returning classification, but it only renders the Livewire component and makes no assertions about the produced datasets/labels. Add assertions against the widget’s chart data (e.g., newActive vs returning counts for the week) so the classification logic is actually verified.

Switching the default test DB from in-memory SQLite to PostgreSQL in phpunit.xml means running the test suite now requires a reachable Postgres instance and an existing relaticle_testing database. If this is intentional, it would help to also set the Postgres connection env vars here (host/port/user/pass) or document the required local test DB setup to avoid surprising failures when running phpunit.

buildActivatedSparkline() counts distinct creator_id for all creators in the period, but the “Activated Users” stat is computed by countActivatedUsers() which only counts creators who also signed up in the same period. This makes the sparkline potentially disagree with the displayed activated-user count. Consider filtering the sparkline query to users.created_at BETWEEN $start AND $end (e.g., join/subquery) so the chart matches the stat definition.

buildWeeklyIntervals() starts intervals at $start->startOfWeek(), which can include days before the selected period start. That will make the first bar include activity outside the requested period. Consider clamping the first interval start to $start (or building intervals from $start and only aligning labels to week boundaries).