Wodby treats databases as first-class building blocks inside an app stack. You can run a database service inside the stack when you want the database close to the app, or use a cloud database service to connect apps to managed offerings such as Amazon RDS.
Container-based databases support imports and automatic backups uploaded to Amazon S3, Google Cloud Storage, Azure Blob, DigitalOcean Spaces, and Wodby lets you manage databases, users, and access rules in the same workflow.
Choose the right database model
Self-hosted in the stack
Useful for fast environments, smaller workloads, and cases where the database should run alongside the app, with imports and automated backups built in.
Managed outside the stack
Use cloud database services when the database should live in a provider-managed service instead.
User and database access control
See databases and users, and manage which users can access which databases from the same platform workflow.
Automatic backups to cloud storage
Container-based database backups run automatically and can be uploaded to Amazon S3, Google Cloud Storage, Azure Blob, DigitalOcean Spaces.
Deployment models
The database page is less about listing engines and more about making it clear when you should run the database in the stack and when you should connect a managed database instead.
Container-based database services support backups and imports, which makes it easier to move data between environments. Backups run automatically and can be uploaded to Amazon S3, Google Cloud Storage, Azure Blob, DigitalOcean Spaces.
Cloud database services keep the integration with managed offerings such as RDS inside the same Wodby workflow as the application.
You can see and control databases and users, and manage which users have access to which databases from the same workflow.
Teams can use self-hosted databases for fast environments and managed databases for production without changing the overall delivery model.
Database catalog
Open a database entry to review the app wiring, stacks that use it, and the surrounding integration details.
Self-hosted databases
Self-hosted database services are the database layer inside the app blueprint. They are useful when the database should be deployed as part of the same stack as the application. They also support imports and automated backups for moving data between environments.
Self-hosted PostgreSQL database service for applications that want Postgres to run as part of the stack.
Source repository
wodby/service-postgresSelf-hosted MariaDB database service for applications that want a relational database inside the same delivery workflow.
Source repository
wodby/service-mariadbPostGIS self-hosted database service for running relational data workloads inside a stack.
Source repository
wodby/service-postgisManaged database integrations
Cloud database services keep managed database connectivity inside the app blueprint, so the integration is still part of the same delivery workflow.
Database connection service for apps that use managed PostgreSQL offerings such as Amazon RDS instead of running Postgres in the stack.
Source repository
wodby/service-cloud-postgresDatabase connection service for apps that use managed MySQL offerings such as Amazon RDS instead of running MySQL in the stack.
Source repository
wodby/service-cloud-mysqlDatabase connection service for apps that use managed MariaDB offerings instead of running MariaDB in the stack.
Source repository
wodby/service-cloud-mariadbStart from the closest database service here, or use the broader service catalog when the workload needs more than a relational database engine.
FAQ
Self-hosted database services run the database as part of the stack. Cloud database services connect the app to a managed database offering instead of running the database inside the stack.
Self-hosted databases are a practical choice for development, staging, smaller workloads, or cases where running the database inside the stack is simpler and more cost-effective. They also support backups and imports for moving data between environments.
Cloud database services are useful when you want the operational model of a managed database, such as backups, scaling, or provider-managed reliability, while still keeping the application integration inside Wodby.
Stacks are the blueprints used to deploy apps, and database services are the database layer inside those blueprints. Apps inherit the database wiring from the stack they use.
Automatic backups for container-based databases can be uploaded to connected cloud storage providers such as Amazon S3, Google Cloud Storage, Azure Blob, DigitalOcean Spaces.
Yes. Wodby lets you see and manage databases and users, and control which users have access to which databases.