July 2, 2026
Table for 50,000? Disaster seated
Too many tables are bad for you
When your app has so many drawers the whole house starts collapsing
TLDR: A real-world database slowdown and memory crash turned out to be caused by an absurd number of tables, which made long-lived connections keep too much stuff in memory. Commenters split between mocking the setup as design chaos and defending it as painfully normal in big corporate systems.
A database expert shared a deceptively simple warning: having way too many tables can quietly wreck your system. In this case, the customer saw two scary symptoms — the server kept running out of memory and long queries were slowing everything to a crawl. The culprit wasn’t some flashy bug or mystery hacker. It was the digital equivalent of owning far too many filing cabinets and forcing every long-running connection to remember more and more of them until memory ballooned.
And yes, the comments instantly turned into a mix of therapy session, roast battle, and support group. The strongest reaction was basically: "Who on earth has tens of thousands of tables?" One camp blamed terrible design and called it a cautionary tale about letting databases turn into hoarder apartments. The other camp jumped in with defenses: sometimes huge systems, customer-by-customer setups, and auto-generated schemas make this mess surprisingly real. That sparked the classic fight between "skill issue" and "welcome to enterprise reality".
The jokes wrote themselves. People compared the database to a kitchen with 50,000 labeled Tupperware lids, a library where every book gets its own room, and an office worker who crashes because they insist on memorizing every folder they’ve ever seen. The darkly funny consensus? PostgreSQL didn’t exactly "break" — it just did what it was told, then ate half a gig of memory per connection like a midnight snack. The vibe in the community was equal parts horrified, smug, and painfully seen.
Key Points
- •The article links a customer's PostgreSQL OOM crashes and CPU-heavy long queries to a database containing too many tables.
- •After disabling memory overcommit, PostgreSQL logs showed memory context dumps and autovacuum workers failing to fork because of low memory.
- •Typical PostgreSQL memory consumers such as shared buffers, work_mem-related backend memory, dynamic shared memory, and large values were considered but were not the main cause in this case.
- •A later memory context dump showed that CacheMemoryContext accounted for the large majority of memory usage, reaching roughly half a gigabyte in one backend process.
- •The article explains that PostgreSQL metadata caches such as catcache and relcache have no fixed size limit and can grow as long-lived connections touch more relations in databases with tens of thousands of tables.