I am generally a huge vertical sharding skeptic but there are special cases where it is beneficial. If you have a simple query pattern on one table that represents a big fraction of your entire workload you can put it into its own instance and it becomes much easier to monitor. It’s easy to see why vertical sharding is sometimes the right answer by inverting the decision: should we put two unrelated large applications on the same instance? Obviously not, there is no benefit and ops becomes more difficult.
I've not evaluated it or ever worked with it myself, but CitusDB has been working on PostgreSQL horizontal scaling for quite some time now, right?<p>Does anyone have positive or negative experiences with Citus?
If you truly reach the limit of vertical scaling with Postgres, 9/10 I guarantee you have some hideously unoptimized schema and queries. The remaining 1/10, I hope, has actual DB experts on staff that know what they’re doing.
Written in 2025 and still acting databases like Cassandra are trendy. It's 16 years old.<p>Stop making excuses for PostgreSQL lacking a built-in, supported horizontal scalability solution.
"Tables (apps) are never really split up. Even in the perfect world, two apps developed by the same company will need to talk to each other"<p>I don't understand why this sentence appears to treat "tables" and "apps" as the same concept. Is this a use of the term "app" that I'm not familiar with?<p>---<p>TLDR of this post is that it's promoting a new open source (AGPL) horizontal sharding solution for PostgreSQL called PgDog: <a href="https://github.com/pgdogdev/pgdog">https://github.com/pgdogdev/pgdog</a><p>Looks like the trick this one uses is to parse your SQL queries inside a custom router/load-balancer and redirect them based on introspecting the WHERE clause of a SELECT/UPDATE/DELETE or the VALUES clause of an INSERT to identify sharding keys: <a href="https://docs.pgdog.dev/features/sharding/query-routing/" rel="nofollow">https://docs.pgdog.dev/features/sharding/query-routing/</a>