You’ve fixed something gnarly in production this year. You’ve migrated a database that nobody wanted to touch. You’ve built something on top of Percona Operators, or Percona Toolkit, or Percona Monitoring and Management (PMM), and you’ve learned things along the way that aren’t written down anywhere yet.

Write it up. We’ll publish it, and we’ll pay you.

The Percona Community Writers Program publishes technical posts from the people actually using these tools — DBAs, developers, contributors, and engineers running real workloads. Posts go up on percona.community/blog under your name, with your bio and links.

For every post we publish, you get:

• $350 paid out after publication
• Community engagement points you can redeem in our swag store for t-shirts, stickers, and other items

The points stack across contributions. The more you write, the more you collect.

Not everyone can accept payment for writing — employment contracts, tax situations, visa rules, and conflict-of-interest policies all get in the way. If that’s you, we’ll donate the same $350 to an open source project or community of your choice on your behalf. Tell us who to send it to when you pitch.

Anything you’ve done with the Percona stack — or alongside it — that another engineer would learn from. Some directions to consider:

• Percona Operators — running databases on Kubernetes, scaling decisions, upgrade paths, what surprised you
• Percona Toolkit — how you use specific tools in your day-to-day, scripts you’ve built around them, edge cases
• Migrations — moving between versions, between database engines, on-premises to cloud, the parts that aren’t in the docs
• Troubleshooting — a real incident, what you saw, what fixed it, what you’d do differently
• Percona Monitoring and Management (PMM) — dashboards you’ve built, alerts that actually catch things, integrations
• Databases themselves — MySQL, PostgreSQL, MongoDB, MariaDB, Valkey, anything in the open source database world you’re hands-on with

We’re not only interested in Percona-product posts. If you’re active in the wider open source database community — contributing to MySQL, PostgreSQL, Valkey, or anywhere else — we want to hear about that work too. Your projects, your perspective, your hard-won opinions.

Every submission is reviewed by the community team for technical accuracy and grammar before it goes live. We’re not gatekeeping — we’re making sure your name goes on something solid.

One firm rule: no AI-generated content. We run every submission through GPTZero and it has to come back clean. We’re publishing your voice and your experience, not a model’s summary of either. If you used AI to help draft, that’s fine — but the post needs to read as yours and pass the check.

Pitch us first. A couple of sentences on what you want to write about and why you’re the person to write it is enough. We’ll reply with feedback, a timeline, and any direction that helps you write a stronger post.

You don’t need to be a published writer. You need to have done something and be willing to explain how. A 900-word post about how you debugged a replication lag issue last quarter is more valuable than a 3,000-word survey of the database landscape.

Send pitches and questions to the Percona Community team — by filling in this form.

Not sure where to start? Here are some directions we’d love to see covered. Pick one, narrow it down to something you’ve actually done, and pitch us.

Databases

• Automating database setup for production in under a few hours
• Backup and disaster recovery strategies that hold up
• Failure stories — what broke, what you learned

DevOps and reliability

• Database Reliability Engineering (DBRE) in practice
• Site Reliability Engineering (SRE) applied to databases
• Monitoring and SLAs that mean something
• Useful scripts you actually run in production
• Testing and QA for database changes

Distributed computing

• Consensus algorithms and real-world implementations
• Synchronous vs asynchronous replication — trade-offs and where each fits

How-tos

• Moving from a single node to a cluster (any DB engine)
• Batch processing patterns
• Stream processing patterns
• Metrics that actually tell you something

Open source

• Measuring your open source project’s success
• Bug squashing done right
• Licensing — what to know before you pick one
• Vendor lock-in and how to spot it early

We pay engineers to share what they’ve learned. That’s the whole offer. If you’ve got something worth writing, write it.

Contributors to the Percona Community Blog retain copyright of their work. By submitting content, authors grant Percona a non-exclusive, worldwide, royalty-free license to publish, distribute, and promote the content as part of the Percona Community platform. Unless otherwise specified, all community blog posts are published under the Creative Commons Attribution 4.0 International (CC BY 4.0) license. ∎