# A Deep Dive into Table partitioning Part 5: Partitioning an environment not individual tables

DevFeed: [A Deep Dive into Table partitioning Part 5: Partitioning an environment not individual tables](<https://devfeed.tech/articles/a-deep-dive-into-table-partitioning-part-5-partitioning-an-environment-not-individual-tables-26252.md>)

Original publisher: [Read original article](<https://medium.com/adyen/a-deep-dive-into-table-partitioning-part-5-partitioning-an-environment-not-individual-tables-a890ca302d86?source=rss----64941d9fbc09---4>)

Author: Adyen

Published: 2026-07-13T09:18:45Z

Content type: article

Language: en

Sources: [Adyen Tech](<https://devfeed.tech/sources/adyen-tech.md>)

Topics: [Databases](<https://devfeed.tech/topics/databases.md>), [PostgreSQL](<https://devfeed.tech/topics/postgresql.md>)

Tags: [adyen](<https://devfeed.tech/tags/adyen.md>), [database](<https://devfeed.tech/tags/database.md>), [deep-dive](<https://devfeed.tech/tags/deep-dive.md>), [partitioning](<https://devfeed.tech/tags/partitioning.md>), [performance](<https://devfeed.tech/tags/performance.md>), [postgresql](<https://devfeed.tech/tags/postgresql.md>), [table-partitioning](<https://devfeed.tech/tags/table-partitioning.md>)

## AI overview

This fifth article in a table-partitioning series explains why partitioning must account for an entire relational database environment rather than isolated tables. It discusses lessons from PostgreSQL partitioning, including table locks, partition maintenance, indexes, foreign keys, and the careful use of default partitions.

## Source excerpt

By Derk van Veen, Database Engineer, Adyen If we had known better, this would have been the first blog post about partitioning to publish. The reality is, the first article was published two years and two weeks ago, as I write these opening sentences. So this article will not only give insight into the most important decisions you will have to make when considering your partitioning planning, but as a bonus, it will give some insights into how much it takes to write an article like this. One of my values is sharing knowledge and giving back to the community. I share what I learn and take people along on my journey and investigations into the problems we've faced. For this reason, the previous articles have documented these learnings, and this one is about a lesson we learned a little too late. The Journey so far Up to this point: We've shared the what, why and when to partition in the first blog post. In the second article, we covered how to maintain partitioned tables, as they provide some additional challenges when it comes to adding/removing partitions and managing indexes and foreign keys. Only in the third article did we disclose why we decided to work on our own partitioning framework: the existing partitioning solutions didn't provide us with the tools to minimize locks on tables. Our databases are always up and pressured, and the locks around partitioning were simply impossible to deal with. The key lesson from this article was that the default partition is the root of (almost) all evil regarding table partitioning in PostgreSQL. In the last article, we shared a cool solution to a problem we faced, where the default partition actually became the hero of the story. Yes, default partitions are usually the root of partitioning evil, but they also provide a welcome exception to the rule. Just be very careful with its usage. The Journey Continues... What ingredients can be missing after reading these four articles? You already know all about partitioning tables by