Demo Note About Backstage Database

Before we wrap up this section, it’s crucial to understand how Backstage manages its data store. By default, Backstage relies on an in-memory database, which only persists data for the lifetime of the process.

Warning

The in-memory database is intended for development and testing only. All registered components and services are cleared whenever Backstage restarts.

The image illustrates a development environment setup with an in-memory database, featuring a restart option. It is titled "Managing Data on Backstage."

In-Memory Database (Development)

Quick to set up: No external dependencies required.
Ideal for prototyping and experimentation.
Volatile storage: data is lost on every restart.

To maintain data between restarts in production, Backstage supports PostgreSQL as its primary database. Configuring PostgreSQL ensures catalog entities remain intact, even after service reboots.

The image is a diagram titled "Managing Data on Backstage," showing a Postgres Database connected to an Auth service within a production environment.

Production Database (PostgreSQL)

Feature	In-Memory Database	PostgreSQL (Production)
Persistence	Volatile	Persistent across restarts
Setup Complexity	Minimal	Requires external database configuration
Scalability	Limited	High
Recommended Use	Development/Test	Production

Note

Later in this lesson, you’ll find step-by-step instructions on integrating PostgreSQL with Backstage, including connection settings and schema migrations.

For more information, refer to the Backstage Database Configuration guide.

Watch Video

Watch video content