Introducing Percona Database Service (PDS): What Happens When an Engineer Just Wants to Try Something
It’s Thursday afternoon, and a developer has an idea.
Nothing complicated. They are working on a new application feature and want to test an idea before committing to a larger implementation. A quick prototype is already running locally. So far, so good. Next, they want to deploy the application to a shared environment so their colleagues can try it out. The application needs a database too, but it needs to be accessible from the shared environment, not just their laptop. And that’s where things get more complicated.
Now they need to submit a request to the infrastructure team, wait for an environment to be provisioned, or spend the afternoon working through Kubernetes configurations. What should have been a quick experiment becomes another task on somebody else’s backlog.
This is a common problem for engineering teams. Getting a database running in a shared environment shouldn’t require extensive coordination or infrastructure expertise. But there is another issue: when an application moves to staging or production, the requirements grow. The challenge isn’t just making provisioning easier, but finding a consistent way to manage databases as applications evolve, without requiring developers and infrastructure teams to go over the same things all over again.
Even when the underlying infrastructure is in place, creating a database with the right configuration, access controls, and operational settings can require several manual steps. And provisioning is only the beginning. Someone still needs to manage backups, monitor resource utilization, handle scaling, and maintain the database throughout its lifecycle.
At Percona, we’ve been exploring how to simplify these workflows while allowing organizations to retain control over their infrastructure. The result is Percona Database Service (PDS), a platform for provisioning and managing databases. We’re starting with MySQL and PostgreSQL on Kubernetes, and we’re making the initial implementation available for users to explore and provide feedback.
The idea is straightforward: bring the simplicity of a managed database experience to infrastructure you control, without the usual vendor lock-in.
How PDS works
PDS follows a relatively simple model: Kubernetes environments connect to a centralized control plane, allowing databases to be deployed and managed within the customer’s infrastructure.
Using Amazon Elastic Kubernetes Service (EKS), PDS provisions databases directly within your AWS account, rather than moving them into a Percona-hosted environment. This allows you to retain ownership of your infrastructure and databases while using PDS as a centralized management platform.
The PDS approach to database creation is intentionally opinionated. PDS provides standardized starting points for common workloads, yet still allows customization when needed. The goal isn’t to hide every technical detail. It’s to simplify and standardize routine database operations while keeping the underlying systems accessible to the teams that operate them.
Connecting an environment is a command, not a form
It starts with a name, which doubles as the EKS cluster name, and one generated command, run locally on a machine that already has aws, eksctl, kubectl, helm, and python3. Nothing gets pasted or copied into a web form; the command does the work, and the environment reports itself in once it is up and running.
That command asks which AWS region to use. Leave it blank, and it uses your AWS CLI’s configured region, or us-west-2 if you haven’t set one. Then it creates an EKS cluster with four t3.2xlarge nodes and an S3 bucket, installs PDS onto it, and registers it. If you point the command at a cluster that’s already running PDS, it reuses that install instead of stacking a second one on top, and turns off that cluster’s own sign-in page in the process.
A database as a profile, not a spec sheet
Creating a database means picking a profile, not filling in a resource calculator: Dev, Staging, or Prod.
Each profile comes with configurations and operational defaults established by Percona’s experts, bringing best practices into the provisioning process. High availability (HA) is the default from Staging up, so it’s not a box you have to know to check. You retain control over your databases and infrastructure, while PDS helps ensure they’re configured according to proven operational standards.
Access is Private or Public. Public adds a load balancer in your own cloud account, billed by your provider, and an allowlist of IPs or CIDR ranges.
Your AI agent can drive it
It is really easy to connect an AI assistant to PDS. PDS provides setup instructions for supported clients, such as Cursor and Claude, enabling you to integrate database management into your existing workflows.
Authentication happens separately from the AI client configuration. Sign in through a browser-based flow, without storing passwords in configuration files or sharing credentials with the assistant. Once authenticated, the agent can start operating. The agent’s actions are recorded, so nothing goes unnoticed.
And then there are permissions you control. Grant read-only access to database information, allow operational tasks such as provisioning, scaling, and backups, or separately authorize actions such as deleting or restoring databases. Allowing an agent to modify databases does not automatically give it permission to delete them.
Managing databases after deployment
Creating a database is only one part of its lifecycle.
PDS provides a database management interface where users can inspect deployment status, review resource metrics, access connection information, and perform supported operational tasks. For example, users can scale database resources, configure scheduled backups, or initiate an on-demand backup. Backup schedules include configurable frequency, execution time, and retention settings. PDS also provides an activity history to help track operations performed through the platform. The interface currently exposes basic operational metrics, including CPU utilization, disk usage, and database connections.
These capabilities are intended to cover common management tasks without requiring users to interact directly with Kubernetes resources for every operation.
Supporting teams and shared environments
In most organizations, the people requesting databases are not necessarily the people responsible for operating the underlying infrastructure.
A development team may need a PostgreSQL instance for an application, while platform or DBA teams remain responsible for infrastructure, security, and operational standards. PDS supports this separation through organizations, teams, and user management. Users can register, create teams, and invite colleagues. Database environments can be organized around teams, creating a foundation for shared management and controlled access.
This is an area we’re developing based on customer feedback. One recurring requirement is to give application teams more independence without losing centralized oversight. That includes questions around permissions, resource limits, and which operations should require additional authorization.
The current implementation provides the initial team and user management capabilities. More granular governance and operational controls are areas we’re continuing to explore.
Integration with Percona Monitoring and Management (PMM)
PDS also integrates with Percona Monitoring and Management (PMM). This gives teams access to deeper database performance monitoring and diagnostics. PMM enables more detailed analysis of query performance, database activity, and potential bottlenecks for PDS users.
Together, they combine simplified database management with the monitoring capabilities Percona users already know and trust.
Try PDS and tell us what you think
We’re making PDS available to learn more about how it fits into real database workflows.
Visit pds.percona.com, create an account, and connect an Amazon EKS environment in your AWS account. From there, you can provision MySQL or PostgreSQL databases, create teams, invite users, configure backups, and explore integrations. We look forward to receiving your feedback:
- Which provisioning steps create too much work?
- What should a standardized configuration include?
- Which operational tasks should be automated?
- Where should the boundaries between developer self-service and managed database be?
This is an early preview, and some functionality will change as development continues. Our goal is to build a practical, open source approach to database management that gives teams more control over their infrastructure, not less.
The post Introducing Percona Database Service (PDS): What Happens When an Engineer Just Wants to Try Something appeared first on Percona.