Docs / 04 / Managed data
Managed PostgreSQL and MySQL databases
Resilis supports managed PostgreSQL and MySQL databases alongside object storage. Choose database placement and protection independently from the application release. An app rebuild or rollback does not replace a database recovery plan, and destructive data actions require your authorization.
Choose and create a database
Before creating a database, identify the engine your app supports, required capacity, intended environment, and connection method. Current managed database creation supports PostgreSQL and MySQL. The recommended defaults are PostgreSQL 17 and MySQL 8.4. Available versions depend on the selected target.
Create the database in the intended project and environment. Keep public access disabled when the application can use an internal connection. The recorded Node.js guide places the app and PostgreSQL database in the same project, environment, and region. It checks database readiness before starting the app and uses disposable sample data.
Review CPU, RAM, persistent disk, and the database service fee before provisioning. The fee applies per database in addition to its resource usage: $5 per month on Hobby or $10 per month on Pro, prorated hourly. Database compute, disk, and service fees draw from runtime credit.
Bind the connection securely
Bind the database connection to a sensitive application environment variable. DATABASE_URL is the default binding name; use the name your application actually reads. Review the selected database and target before changing the variable. Keep the connection value out of source control, prompts, logs, terminal history, and screenshots.
Check that the app can resolve and reach the chosen connection endpoint. The app must run where it can reach the internal database endpoint. If startup fails, inspect the selected environment, binding name, and connection settings without printing the secret. Keep the database private while correcting its placement or connection settings.
Check that data persists
Create and read a disposable record through the application, rebuild the app, and read the same record again. The PostgreSQL task board guide records this check. Its app fails to start when PostgreSQL is unavailable instead of switching to memory storage.
Persistence across an app rebuild is different from recovery after deletion or data corruption. Review the backup configuration and available recovery points before depending on a restore. Keep independent copies of irreplaceable data and test recovery with disposable data before using the procedure during an incident.
Snapshots and point-in-time recovery
Hobby includes snapshots. Pro and above include point-in-time recovery, or PITR, entitlement for supported database protection paths. PITR reconstructs a database at a selected time using the configured archives. PostgreSQL and MySQL use different protection mechanisms; available archives and restore points determine whether the requested time is recoverable.
Review the engine, protection configuration, and available restore points before requesting recovery. Choose the database and recovery point, then authorize the restore. After it finishes, check the restored application data and connection configuration. Recovery uses the archives available for that database.
App rollback changes an application release and does not restore database data or reverse migrations. Check schema compatibility separately. These protection features do not establish a guaranteed recovery time, recovery point objective, or uptime commitment.
Managed object storage
Use managed object storage for bucket and object workflows through an S3-compatible backend. Keep bucket credentials separate from source and configure only the access your app needs. The published storage rate is $0.035 per GiB-month, prorated hourly. Object storage and persistent disk use separate meters.
Hobby permits 5 buckets and Pro permits 25. Bucket limits set how many buckets you can create; storage charges follow usage. Object storage and egress draw from runtime credit, just like compute, persistent disk, and database fees. Review storage and transfer usage as the app grows.
Connect existing S3, R2, or B2 storage
Customers can connect an existing Amazon S3, Cloudflare R2, or Backblaze B2 bucket. Prepare an accessible bucket, the provider endpoint, and credentials with the required permissions. Register that connection with Resilis and verify an intended object operation using disposable data. Keep credentials private and review connection limits for your account.
Registration connects the existing bucket; it does not provision a new provider bucket or migrate objects. Your provider account and charges remain separate. Applications can also connect to external databases or backends such as Supabase or Convex through their own connection settings. Those services are not Resilis-managed database offerings.