Skip to main content
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.
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)

FeatureIn-Memory DatabasePostgreSQL (Production)
PersistenceVolatilePersistent across restarts
Setup ComplexityMinimalRequires external database configuration
ScalabilityLimitedHigh
Recommended UseDevelopment/TestProduction
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