Managed PostgreSQL, MySQL & Valkey
Building an app is enough work. DBTurbine brings your database, connection details, access controls and recovery tools into one workspace—so running a server doesn’t become your second project.
PostgreSQL
MySQL
ValkeyWorkspace preview with sample data.
Installing the database is only the beginning.
Firewall rules. User permissions. Certificates. Backups that need checking. Updates that need a sensible time to restart. These jobs are easy to put off until something breaks. We’re building DBTurbine to make them part of the setup, with controls you can understand when you need them.
DBTurbine is in development. Explore the sample workspace today; paid deployments open after provisioning and recovery have been tested.
Choose your engine
Your application shouldn’t need a different query language or a special library just to change where its data lives.
For applications with more to query.
Keep your relational data, work with JSONB, and write the joins your application needs. PostgreSQL gives you transactions, constraints and expressive SQL for everything from a small product database to a reporting workload.
For the applications you know well.
If your application already uses MySQL, keep the engine it was built for. InnoDB tables provide transactions and foreign keys, with a broad choice of clients and connectors for web applications and existing systems.
For the work that needs a fast key lookup.
Keep application caches, session data and counters close to your application. Valkey uses familiar Redis-compatible clients, with encrypted connections and scoped access to key prefixes.
Already running a database? Start with the same engine and a compatible version. A hosting move is simpler when you’re not rewriting your application at the same time.
Connect your application
Use your usual database driver, ORM or SQL client. Your workspace is designed to put the host, port, certificate and connection instructions together, without making you look through a server configuration file.
Give each application its own user. Keep credentials in your application’s secret settings, and allow the IP address it connects from.
Read the connection guidepsql "host=db.example.com port=5432 dbname=app user=app_user sslmode=verify-full sslrootcert=/path/to/ca.pem"SELECT name, email
FROM customers
WHERE created_at >= CURRENT_DATE
ORDER BY created_at DESC; name | email
--------------+-----------------------
Morgan Lee | [email protected]
Alex Rivera | [email protected]
(2 rows)Example only. Replace the endpoint, username and certificate path with your own connection details.
Access that you can check
Your app needs to read and write its data. A reporting tool might only need to read it. Give them different users and permissions, so one set of credentials doesn’t do everything.
Add the public IP addresses of the applications and tools that need access. Avoid opening the database to the entire internet just to make a connection work.
Use TLS with certificate verification in your client. Encryption protects the connection; verification helps confirm that it reaches the expected server.
Backups & recovery
A full backup gives you a starting point. Recovery logs fill in the changes after it. Together, they can recover a database to an available moment before a bad migration or an accidental delete.
The planned restore flow keeps the original instance intact. Restore a separate copy, inspect your data, then switch your application when you’re ready.
How backup coverage worksCheck your data before switching.
Available times depend on completed backups and continuous recovery log coverage.
A complete backup is stored away from the database server. Keeping everything on one machine would also put the backup at risk if that machine fails.
Recovery is limited by your plan’s retention and the logs successfully stored. The workspace should show the actual available window, rather than assume every moment is recoverable.
A restore doesn’t automatically replace your live database. A separate instance gives you a chance to check it first and may incur additional instance charges.
The day-to-day work
A useful control panel should make the common jobs easy to find, and make consequential changes clear before you confirm them.
Keep track of databases, create application users and review the access each one has. A production app and a reporting tool don’t need identical permissions.
See how much space the database is using and how many connections are open. Use those numbers to decide when a larger plan makes sense.
Find completed backups, inspect recovery coverage and follow the progress of a restore. A failed backup should be visible, not quietly counted as protection.
Choose a window for routine work. Restarts can interrupt connections, so your application should reconnect safely. Major upgrades need a separate compatibility check.
What managed means here
We’re starting with single-instance PostgreSQL, MySQL and Valkey deployments. That keeps the service straightforward, but it’s important to understand where its protection ends.
Maintenance & upgrade guideProvisioning, database installation, network rules, certificates, backup scheduling and planned maintenance belong in the service.
You control the schema, queries, migrations and application credentials. Test changes before running them against production data.
A dedicated deployment is one instance, not a high-availability cluster. There is no automatic failover in the initial offering. Recovery and maintenance can involve downtime.
Before you move your data
More detail now makes for a better decision later.
Start with the engine your application supports. PostgreSQL is useful when you need complex queries, JSONB or richer data types. MySQL is a natural fit for applications already built around it. Moving an existing application usually means keeping its current engine, rather than changing both the database and the hosting at once.
The migration approach depends on your engine, database size and acceptable downtime. A small database can often be moved with a dump and restore. Larger or busy databases need more planning. Check engine versions and extensions first, and test a copy before switching the application’s connection.
No. The initial service is designed around one instance per deployment. That separates your database server from other customers, but it does not provide a standby server or automatic failover. Backups help with recovery; they do not keep an application running during an outage.
A full backup is the starting point. PostgreSQL’s write-ahead logs or MySQL’s binary logs replay subsequent changes up to an available recovery time. The intended restore flow creates a separate instance so you can inspect the recovered data before changing your application’s endpoint. Recovery is limited to the completed backup and log coverage shown in your workspace.
Yes. The service is designed to use standard PostgreSQL and MySQL connections. You can connect from your application, command-line client or a desktop tool such as DBeaver. Your client needs to support the database version, verify its TLS certificate, and connect from an allowed IP address.
Routine updates are planned for a maintenance window and may require a restart. Major version changes need compatibility checks and a tested migration to a separate instance. They should not happen as a surprise upgrade to your production database.
Practical guides for the first connection, safer access and planning a recovery.
Explore the workspace before you decide on a plan.