Use cases · Databases and stateful services
Production dataWithout a database project
Add the database next to the app. We keep it running so you can keep building.
app
storefront
web process
engine
orders-db
{{ orders-db.POSTGRES_URI }}
In the product
The database is a service on the app.
Name it, pick the engine, and the app keeps a private reference.
Before
The URI gets copied. Then it drifts.
Every service pastes the secret. Rotate once, and half the stack is stale.
reference
{{ orders-db.POSTGRES_URI }}
One source. Consuming apps read the reference.
Engines
The engine your app already uses.
Pick the engine. Port, version, and connection key come with it.
Network
Private by default.
The app reaches the engine on the worker network. Public exposure is a choice.
exposed
public URI
Open to the internet until someone remembers to lock it.
private
service reference
Reachable from services in the same environment.
Recover
Retention is visible before the incident.
Hourly, daily, and weekly keep windows stay on the database where backups are supported.
now
live
6h
hourly
24h
daily
7d
weekly
data
Attach the database.Keep the app connected.
{{ orders-db.POSTGRES_URI }}
Use dFlow when application data should stay close to the workload and readable to the team.