---
title: "Jobs log datasource breaking change"
excerpt: "Important changes to job type reporting in the jobs_log datasource"
date: "2025-07-21"
---

# Jobs log datasource breaking change

### Job type "populate" changing to "populateview"

{% callout type="warning" title="Breaking change" %}
Starting August 1, 2025, Tinybird will change how "populate" jobs are reported in the `tinybird.jobs_log` datasource. The `job_type` field will show "populateview" instead of "populate" for new job entries.
{% /callout %}

Starting on August 1, 2025, when you query the `tinybird.jobs_log` datasource and filter by `job_type = 'populate'`, the query will stop returning results for new job entries. You will need to update your queries to use `job_type = 'populateview'` instead.

If your app currently monitors or processes jobs using the "populate" job type, you will need to update your code to handle "populateview" instead. This includes:

- Monitoring dashboards that track populate job performance
- Automated scripts that filter or process populate jobs
- Any alerting systems based on populate job status

We are making this change to align the Jobs API validation with the actual job system implementation and resolve inconsistencies between our documentation and API behavior. This change is part of our ongoing effort to standardize job type naming across all Tinybird systems.

**Migration recommendations:**

- Update your queries to use `job_type = 'populateview'` before August 1
- Consider using `job_type IN ('populate', 'populateview')` during the transition period if you need to query both old and new job entries
- Test your monitoring and alerting systems with the new job type name

This change will go live on August 1, 2025. We recommend updating your apps and monitoring systems well before that date to ensure a smooth transition. If you have any questions or concerns, reach out through our usual support channels.

## Deployments now report the data that will be copied

The output of the `tb deploy` command now includes a section that reports the data to be copied
during the deployment.

```{% title="tb deploy output with data copied" %}
 Data that will be copied with this deployment:
---------------------------------------------------------------
| Datasource | Backfill type                                  |
---------------------------------------------------------------
| events     | From live deployment using Forward Query       |
| processed  | Using Materialized Pipe process_events         |
---------------------------------------------------------------
```

Or like this when no data will be copied:

```{% title="tb deploy output no data copied" %}
* No data will be copied with this deployment
```

## Skip backfilling a new Data Source

By default, when you create a Data Source that is the destination of a Materialized View, it is
automatically backfilled with the results of the Materialized View's query. You can now skip this
behavior by adding the following to the end of the new `.datasource` file:

```tb {% title="Skip initial backfill" %}
BACKFILL skip
```

## Observability of the memory consumption of your endpoints

Now you can track the memory consumption of your API endpoints with the new `memory_usage` column in `tinybird.pipe_stats_rt`. This new metric helps you identify inefficient queries and optimize endpoint performance.

The `memory_usage` field shows the memory consumption for each query in bytes. High memory usage can indicate:

- Complex operations that need optimization
- Large result sets that could be paginated
- Unoptimized queries that scan more data than necessary

Use this data to monitor and improve your endpoint efficiency. For example, you can find endpoints with the highest memory usage:

```sql
SELECT
    pipe_name,
    formatReadableSize(avg(memory_usage)) as avg_memory_usage,
    count() as request_count
FROM tinybird.pipe_stats_rt
WHERE start_datetime >= now() - INTERVAL 24 HOUR
GROUP BY pipe_name
ORDER BY avg(memory_usage) DESC
```

Learn more about monitoring endpoint performance in our [performance analysis guide](/monitoring/analyze-endpoints-performance).

You can also visualize memory usage trends over time to identify patterns and spikes in memory consumption:

{% image src="/assets/changelog/timeseries_memory_usage.png" alt="Time series chart showing memory usage trends for API endpoints over time, helping identify performance patterns and optimization opportunities" /%}

## Improvements and bug fixes

- [All]: Improved consistency in job type naming across the Jobs API and internal systems.