Backstage Weekly ยท Issue 136

Catalog Export, Query Performance and v1.52.0 Preview

The week after v1.51.0 stable, three features landed on main targeting v1.52.0: streaming catalog export, a 2-3x speedup on entity-list queries, and an OpenAPI auto-onboarding skill for backend plugin authors.

David Tuite
ยท

News

The week after v1.51.0 stable, three features landed on main targeting v1.52.0: streaming catalog export, a 2-3x speedup on entity-list queries, and an OpenAPI auto-onboarding skill for backend plugin authors. Community plugins are completing their v1.51.0 compatibility updates.

Catalog Export, Query Performance and v1.52.0 Preview

Catalog export and query performance in v1.52.0

No new release this week, but two significant PRs merged for v1.52.0 (targeting June 16).

PR #31837 by the-serious-programmer adds streaming CSV and JSON export to catalog index pages. The export dialog lets users select which columns to include. The implementation uses async generators to stream data directly to disk rather than buffering the full dataset in memory, so it handles large catalogs without memory pressure. On the legacy frontend system, it's opt-in via <CatalogIndexPage exportSettings={{ enabled: true }} />; on the new frontend system, it's config-driven in app-config.yaml. Rugvip approved the PR before merge. The underlying feature request (#28960) has been open since February 2025.

PRs #34323 and #34324 by freben address a PostgreSQL performance ceiling in the catalog's queryEntities method. The previous implementation used a Common Table Expression that PostgreSQL 12+ materializes before applying LIMIT, forcing a full filtered-dataset scan on every paginated query. The fix splits list and count into separate queries running concurrently via Promise.all. On a "Kind=component" first-page query, wall-clock time drops from 2.7s to approximately 1s. An unfiltered first page drops from 7.7s to approximately 5.5s. Both target v1.52.0.

From the Roadie blog

We published Context Engineering for Developers: The Infrastructure Layer That Makes AI Actually Useful in April, and the catalog improvements landing this week connect directly to its central argument.

The post separates context engineering from prompt engineering. Prompt engineering is the interaction layer. Context engineering is the information architecture beneath it: how service metadata, ownership graphs, and operational annotations get structured, indexed, and delivered to AI systems at query time. The problem it names - "locally correct and globally invalid" suggestions from AI coding tools - comes from models that can't see the organizational context behind the code they're editing.

The practical starting point it recommends is metadata coverage: four specific fields - owner, system, dependsOn, and operational annotations like runbooks and SLO targets. The export capability merging for v1.52.0 this week is a direct enabler of that audit. Teams can now pull a structured snapshot of their catalog to check which entities are missing which fields before adding AI capabilities on top. The query performance improvement means that audit-and-refresh loop gets faster as the catalog grows.

Read it on the Roadie blog.

Community

๐Ÿ”ง PR #34179 by aramissennyeydd adds a skill to auto-onboard backend plugins to Backstage's validated OpenAPI tooling. Running it migrates a plugin's router to createOpenApiRouter, generates typed request handlers from the OpenAPI spec, and optionally sets up Jest test integration and client generation. Recommended by drodil; targeting v1.52.0.

๐Ÿ› PR #34347 by koalaty-code fixes a column type mismatch in catalog incremental ingestion: the last_error field was incorrectly typed, causing storage failures when ingestion errors were logged. If you're using the Microsoft Graph incremental ingestion module from v1.51.0, this fix is in main and targeting v1.52.0.

โšก PR #34344 by mclarke47 changes the Kubernetes backend to pool HTTPS agents per cluster in KubernetesFetcher rather than opening a new connection per request. For environments with many Kubernetes entities or frequent catalog refresh cycles, this reduces connection overhead across each catalog update.

๐Ÿ”Œ PR #8815 by jmezach adds New Frontend System support to the Octopus Deploy plugin, removing the need to bridge back to the legacy system for teams on the NFS migration path.

What shipped

  • @backstage-community/plugin-rbac-backend - compatibility bumped to v1.50.4
  • @backstage-community/plugin-argocd - compatibility bumped to v1.50.4
  • @backstage-community/plugin-servicenow - compatibility bumped to v1.50.4
  • @backstage-community/plugin-quay - compatibility bumped to v1.50.4
  • @backstage-community/plugin-octopus-deploy - new frontend system support (PR #8815, jmezach)
  • @backstage/plugin-catalog-backend - queryEntities list/count split into concurrent queries; 2-3x speedup on broad first-page queries (targeting v1.52.0)
  • @backstage/plugin-catalog-react - redundant entity fetches eliminated on filter initialization (targeting v1.52.0)
  • @backstage/plugin-kubernetes-backend - HTTPS agent pooling per cluster in KubernetesFetcher (targeting v1.52.0)