Self-host PostgreSQL and ClickHouse
Run managed databases on your own servers. Choose PostgreSQL for app data and transactions, or ClickHouse for analytics over large event datasets.
RunOS provisions databases on your Kubernetes cluster and gives you logs, status, and resource metrics. Choose PostgreSQL for application records and transactions. Choose ClickHouse for analytical queries over large sets of events.
Start with the queries your app needs
For a booking app, keep bookings, users, and payments in PostgreSQL. A transaction can reserve a slot and record a booking together. Start with PostgreSQL for simple reports too, and measure query load before you add another database.
If you need to group large volumes of page views or events by day, country, or campaign, evaluate ClickHouse. Keep PostgreSQL as the source of truth for bookings. Send the events you need for reporting to ClickHouse, and plan how to replay them if the analytics database needs a rebuild.
If your app already depends on MySQL, use the managed services catalog to check what you can keep. A database migration is a separate decision from where to run the app.
Connect the app
Add a PostgreSQL service in the Console or with the CLI. In runos.yaml, point a requires entry at the service ID. Give the entry a database name and username, and map the connection URL to an environment variable your app reads. RunOS injects that variable at deploy time.
For ClickHouse, configure the client endpoint and credentials in your app. See the managed services guide for the services that RunOS can wire through requires.
Plan for node loss and recovery
The default storage lives on one node. Before you load production data, decide how the database should recover from a node failure. Choose a supported replica configuration for database failover. Use distributed storage when you need volumes that can survive a node loss. For ClickHouse, choose shard and replica counts based on your workload and node count.
Backups need explicit configuration. For PostgreSQL, set up an S3-compatible destination and test a restore into a separate instance. For ClickHouse, decide what you need to back up and what you can rebuild from source events. Test the recovery path before you depend on it.