Partitioning in Postgres, 2022 Edition

Is Postgres ever going to allow automatic partitioning?<p>Something like:<p><pre><code> CREATE TABLE logs ( time TIMESTAMPTZ, data JSONB ) PARTITION ON time IN INTERVAL &#x27;1 day&#x27; </code></pre> And it just creates&#x2F;manages these partitions for every day?<p>If you can already manage partitions like this manually it feels like the next step is to just have it be automatic. So you have less of a need to switch to Timescale or ClickHouse or whatever other database as the amount of data you&#x27;re storing&#x2F;querying grows. (Yeah that&#x27;s a handwave-y suggestion but at least you could stick with Postgres for longer.)

I am building my own database engine using some data objects (key-value stores) I invented to form columnar store tables. It has some really fast query speeds and analytic features (e.g. pivot tables) that test favorably compared to Postgres and other RDBMS offerings. (<a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=OVICKCkWMZE" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=OVICKCkWMZE</a>)<p>Partitioning a big table is definitely on my TODO list. How big does a typical table need to grow before partitioning is seen as a &#x27;necessity&#x27;? What are some ways current partitioning strategies have made things too difficult?

We use Postgres partitioning quite successfully to handle our customer based data. Everything is partitioned by customer and some customers are partitioned further.<p>One gotcha to be careful with is that if you run a query spanning multiple partitions, it will run them all at once and if your database isn&#x27;t super big - will bring it to its knees.<p>Outside of that really no issues. We also use Timescale quite heavily, which also works fantastic.

How do people partition with a requirement where you also need unique index constraints (across all partitions)?