Percona Blog
percona.com · Company blog · on HN since 2008
Percona's company blog on open source database operations, covering MySQL and PostgreSQL performance, schema changes, indexing and tooling.
What HN saysCommenters mention Percona mainly as a company offering commercial support for MySQL forks and other open source databases, and it also appears in job posts.
327HN people shared it
201linked it in comments
296stories submitted
4.3Kstory points
3 months agolast shared
2008people per year2026
Most-shared posts
- 1Pt online schema change10 people · first shared 2012
- 2UUIDs are popular, but bad for performance (2019)7 people · 270 points · first shared 2020 · 232 comments on HN
- 3Pt online schema change7 people · first shared 2020
- 4Automatic Index Recommendations in PostgreSQL using pg_qualstats and hypopg5 people · 33 points · first shared 2019 · 3 comments on HN
- 5Percona Website Redesign5 people · 1 points · first shared 2012 · 1 comments on HN
- 6Blog5 people · first shared 2016
- 7PostgreSQL and MySQL's Peaceful Battle at Today's Demanding Workloads4 people · 10 points · first shared 2017 · discussion on HN
- 8Percona server4 people · first shared 2012
- 9Store uuid optimized way4 people · first shared 2017
- 10Mysql zfs performance update4 people · first shared 2021
- 11Percona monitoring and management4 people · first shared 2018
- 12Pt online schema change4 people · first shared 2018
- 13Careers4 people · first shared 2019
- 14MySQL vs. MariaDB: Reality Check3 people · 161 points · first shared 2017 · 64 comments on HN
- 15Linux Fsync Issue for Buffered IO and Its Preliminary Fix for PostgreSQL3 people · 140 points · first shared 2019 · 37 comments on HN
What HN people wrote when they linked it
stephaniedeer · 2021-12-01
Percona | Senior Golang Software Engineer | REMOTE ONLY | Worldwide
The Senior Golang Software Engineer will help us bring Open Source databases to Kubernetes. Our team is small, so you and your work will significantly impact the Kubernetes ecosystem. This is a rare opportunity to work from home with a great team, on a 100% open source project!
https://jobs.lever.co/percona/3fe2bba0-cc07-4eaf-83cc-9d9c956b5ddc?lev…
https://www.percona.com/
nataliyapercona · 2020-05-01
Percona | REMOTE (WORLDWIDE) | Full-Time | https://www.percona.com/
Percona is a leader in providing best-of-breed enterprise-class support, consulting, managed services, training and software for MySQL®, MariaDB®, MongoDB®, PostgreSQL® and other open source databases in on-premises and cloud environments.
We are looking for a Golang Developer who knows how open source databases should run in Kubernetes and who can help us to build high availability clusters
Apply here: https://www.percona.com/about-percona/careers/golang-software-engineer…
Also Database Engineers are very welcome to join our team!
Jobs here: https://www.percona.com/about-percona/careers
Bender · 2026-01-24
Percona [1] mentioned in the article have commercially supported their fork of MySQL for quite some time. It's free to use but they offer support if required. It is used by many large companies and I know the DBA's have had great experience with it at two large companies I worked at. Percona have some really sharp people.
[1] - https://www.percona.com/mysql
LinuxBender · 2025-03-21
Not as far as I know but here is a brief history. [1] They will commercially support all the databases including MariaDB. Their goal was to collectively update MySQL to take advantage of modern hardware. They are also useful for companies that have complex replication and backup requirements. They have also created a lot of tools for DBA's to manage data. The DBA's I worked with had a great relationship and great experiences with them.
[1] - https://www.percona.com/sites/default/files/The-Story-of-Percona.pdf
smueller1234 · 2025-02-17
Was about to say that we managed upwards of 4k servers worth of MySQL databases (as in 4k baremetal servers worth, not 4k small VMs each having a small MySQL) using "Orchestrator" at Booking.com ten years ago. I checked if it was still kicking before writing this and found that the GitHub repo was archived last year. The next Google hit I find is this article from three days ago:
https://www.percona.com/blog/orchestrator-for-managing-mysql-high-avai…
Please do some additional research into the state of maintenance of that piece of tech before jumping on it. But it certainly did a lot of powerful things for us back in the day. The automatic promotion of followers was key to our deployment.
danudey · 2023-07-05
It's worth noting that, while LVM can support snapshots for XFS (or any other filesystem, really), the performance penalty is almost entirely unacceptable (one benchmark[0] shows an up to 60% drop in write throughput), so ideally your process should be something like
1. Snapshot LVM volume
2. Mount the LVM volume and back the snapshot up somewhere else
3. Delete the snapshot as soon as possible
Otherwise you're going to lose a ton of performance.
[0] https://www.percona.com/blog/disaster-lvm-performance-in-snapshot-mode…
grafelic · 2023-04-25
Check out https://www.percona.com/blog (filter for MySQL)
I have been a heavy user of the Percona distribution of MySQL for many years and highly recommend it. I think that most of the MySQL articles on percona.com are relevant for other MySQL distributions.
As a side note, depending on the software stack, ProxySQL can have a major positive impact on performance and scalability.
bratao · 2023-04-06
I´m very sad that MariaDB is in this state. MySQL it still a very powerful database. For someone looking for alternatives, I recommend the Percona Distribution of MySQL. https://www.percona.com/software/mysql-database/percona-server
addisonj · 2023-03-18
This is a great resource.
The PG docs are generally quite good, but logical replication is one of those things where experience and this sort of resource is invaluable.
That said, I also feel like logical replication is still pretty hard to use. One example, not covered here, is that the status of slots is not replicated to any secondaries. There are solutions for this now (see https://www.percona.com/blog/how-patroni-addresses-the-problem-of-the-… but generally the domain of dealing with logical changes is still one where I feel like MySQL binlog has a leg up (though still some sharp edges) in making it a bit easier to work with.
hardwaresofton · 2023-02-09
Don't know how many other people have a bunch of percona links saved since they often have great writeups and experiments -- was blown away with the new site design!
Not crazy about the scroll-jacking animation but that page is quite aesthetically pleasing, and and old articles are still functional and decently laid out:
https://www.percona.com/blog/settling-the-myth-of-transparent-hugepage…
gpderetta · 2022-05-18
darkwater · 2022-05-05
If you are using MySQL I also recommend Percona's Online Schema Change [1] which is basically a robust implementation of this post's algorithm, handles more edge-cases, has been existing for at least 10 years now and works better out of the box with AWS RDS than Gh-ost. (if you have production experience on 100s of millions rows tables with Gh-ost on RDS please share your experience/tricks, I'd love to hear them!)
[1] https://www.percona.com/doc/percona-toolkit/3.0/pt-online-schema-chang…
jakobdabo · 2022-03-25
I'm not sure if Percona's HA solutions are any better than what MariaDB offers, but it's not in your list, so maybe worth mentioning.
https://www.percona.com/services/support/high-availability
https://www.percona.com/blog/2021/04/14/percona-distribution-for-mysql…
avi_vallarapu · 2022-01-17
This is actually a missing piece in Postgres. It was neatly blogged here. https://www.percona.com/blog/2020/05/21/failover-of-logical-replicatio…
tristor · 2021-12-15
Greatly depends on the database in question. For MySQL I heavily recommend using pt-online-schema-change[1] from Percona Toolkit[2].
In all cases though you should have a change management process where the schema change is documented, reviewed, and approved and only a small number of people have the necessary access to run these types of changes in production. Change management is your friend.
1: https://www.percona.com/doc/percona-toolkit/3.0/pt-online-schema-chang…
2: https://www.percona.com/software/database-tools/percona-toolkit
SEJeff · 2021-03-31
A few different points of view:
https://tomharrisonjr.com/uuid-or-guid-as-primary-keys-be-careful-7b2a…
https://news.ycombinator.com/item?id=14523523 (the hacker news comments for the above article are really insightful)
https://www.percona.com/blog/2019/11/22/uuids-are-popular-but-bad-for-…
https://blog.codinghorror.com/primary-keys-ids-versus-guids/
nine_k · 2020-07-09
Unfortunately every index takes time to access; it's like dereferencing a pointer. You also usually want the hottest indexes to reside in RAM. Making more indexes compete for RAM pages may and will have implications for other queries, possibly more important.
I agree that often machine resources are plentiful, and human resources are scarce, so managing indexes automatically makes sense. It's even implemented, e.g. in Oracle as a complete management tool [1], or in Postgres as a discovery and recommendation tool [2].
[1]: https://oracle-base.com/articles/19c/automatic-indexing-19c
[2]: https://www.percona.com/blog/2019/07/22/automatic-index-recommendation…
zokier · 2020-05-17
I'd also be curious about this. C10k was a problem at the turn of the century but world has changed a lot since, both in terms of hardware and kernel.
Best reference I could easily find was this experiment that had 100k connections to mysql which has thread per connection model. Seems to handle it well
https://www.percona.com/blog/2019/02/25/mysql-challenge-100k-connectio…
PeterZaitsev · 2019-11-01
Percona has many open positions for folks who loves Open Source and Database Technologies.
We're remote-first company so whenever you're based you're encouraged to apply
https://www.percona.com/about-percona/careers
sytse · 2019-10-03
I love the partitioning improvements in PostgreSQL 12 https://www.2ndquadrant.com/en/blog/partitioning-enhancements-in-postg… We are planning to use them for GitLab.com, particularly for the events table.
More information is at https://www.percona.com/blog/2019/05/24/an-overview-of-sharding-in-pos… (including a comparison to MongoDB) and https://momjian.us/main/writings/pgsql/sharding.pdf
amaccuish · 2019-08-06
False.
> But it does not seperate table data into one file per table
That's because if you didn't have it set when creating the database, it won't move data to the new fs layout when you set the setting on, without an OPTIMIZE. If you had it on from the beginning, table data is per file. I literally just did an ls on my /va/lib/mysql and there's a folder per database, in which there are 2 files per table (.frm and .ibd).
When innodb_file_per_table is on, and the database has been OPTIMIZEd, only the following is stored in ibdata1 [0]:
- data dictionary aka metadata of InnoDB tables
- change buffer
- doublewrite buffer
- undo logs
[0] https://www.percona.com/blog/2013/08/20/why-is-the-ibdata1-file-contin…
qwerty456127 · 2019-04-30
Here is a great related article I can recommend:
https://www.percona.com/blog/2014/12/19/store-uuid-optimized-way/
otterley · 2018-11-12
The flip side is that GUIDs take up a ton of space and are full of entropy, which makes them very inefficient to work with, are not cache-friendly, and not sortable. Certain database engines (e.g., InnoDB on MySQL) also limit the length of primary keys for performance reasons, which disqualifies GUIDs from being used. With clustering, short keys are better as they reduce IOPS required to fetch data.
See https://www.percona.com/blog/2006/10/03/long-primary-key-for-innodb-ta… for an interesting discussion of the topic.
In general, it's unwise to make recommendations about what data types to use, especially for primary keys, without thorough research on their implications.
TurningCanadian · 2018-04-25
MySQL makes some of the same assumptions about memory. You have to tune it if you want optimal performance.
https://www.percona.com/blog/2016/05/03/best-practices-for-configuring…
morgo · 2018-04-19
Former MySQL Product Manager here (no longer affiliated).
I've been to a Monty talk about this subject, and let me say it was interesting...
Monty starts by saying that he does not acknowledge MySQL 5.6's existence since some new features are an abomination (usually citing GTIDs).
He then compares MySQL 5.5 to MariaDB (of which MariaDB is based on MySQL 5.5; so it contains the superset of features).
MySQL 5.5 was released in 2010. Support for it will end at the end of this year.
Development has diverged a lot since 2010. For a more balanced comparison, I recommend this one:
https://www.percona.com/blog/2017/11/02/mysql-vs-mariadb-reality-check…
bpicolo · 2017-10-19
Sure. The most direct argument against that is that Postgresql jsonb is just non-relational data support in a first class relational DB, which is pretty great, so to an extend you get the best of both worlds, though I'm sure you can find a case where it's not quite optimal vs some nosql db.
This talk is a pretty nifty perf overview:
https://www.percona.com/live/e17/sessions/high-performance-json-postgr…
That said, if you know beforehand that horizontal scaling will be a crucial factor, probably postgres isn't the first choice. But with how fast CPUs are these days it's usually not important for a long time.
falcolas · 2017-06-16
I found the talk slides, but no followup
https://www.percona.com/live/mysql-conference-2015/sites/default/files…
tveita · 2017-04-26
The linked https://www.percona.com/doc/percona-toolkit/2.1/pt-online-schema-chang… generally works really well though, and in the simplest case it's as easy as following the usage example. I'm surprised that they knew about it yet didn't invest the time to learn it.
kasabali · 2017-01-30
RHEL has had a similar behavioral change during lifetime of a release so this particular case is not actually a good example for recommending RHEL over Ubuntu for stability.
https://www.percona.com/blog/2014/04/28/oom-relation-vm-swappiness0-ne…
kostja_osipov · 2017-01-27
We provide multiple solutions for sharding, ranging from https://github.com/tarantool/twemproxy-docker twemproxy port to https://github.com/tarantool/shard.
Tarantool is close to a data grid in its architecture and features from the database world do not apply 1:1.
We have been working on a general-purpose resharding for over 3 years, but have yet to release it to the open source community: it's very hard to do it well.
But our customers get a sharding scheme that best suits their business needs, including fully automatic shard management and data re-balancing. I submitted a talk about the technology and know-how behind this to Percona Live 2017: https://www.percona.com/live/17/sessions/best-practices-application-le…