Deceptive query plans (eg. due to very specific write shapes), lack of QoS classes (to priorize OLTP requests over OLAP ones without spawning a read replica), manual partitioning that is way too manual, lack of backpressure during replication (WAL accumulate and Postgres continues accepting writes) and lack of first-class leader-election mechanism (eg. something like what sorintlab/stolon does) are my top 5 issues with PostgreSQL. Glad to see that one of my 5 pain point (that I call "QoS classes") is shared and addressed, I'm sure on-call engineers will thank you, this work addresses real operating issues.
and keep paying, and paying, and paying... forever.
I worked for a startup who decided on AzureSQL, the costs means they were reluctant to have too many environments and ones of the same size, and the cpu/memory was below what they would have if they had self hosted a free database.
Potgresql has chosen by many PAAS, SAAS and IAAS companies like Superbase, PlanetScale, Cloudflare and to meet there needs they are producing extensions like this one so it's future is very bright.
We know about Resource Governor and wanted to bring something as good or better to Postgres. SQL Server classifies whole sessions into a budget. Traffic Control classifies individual queries instead. That's better granularity, especially when a pooler multiplexes multiple different workloads into a session. It also opens up more flexible classification, e.g., based on query plan or based on sqlcommenter tags carrying information about client apps, job queues, priority levels, or release versions.
Deceptive query plans (eg. due to very specific write shapes), lack of QoS classes (to priorize OLTP requests over OLAP ones without spawning a read replica), manual partitioning that is way too manual, lack of backpressure during replication (WAL accumulate and Postgres continues accepting writes) and lack of first-class leader-election mechanism (eg. something like what sorintlab/stolon does) are my top 5 issues with PostgreSQL. Glad to see that one of my 5 pain point (that I call "QoS classes") is shared and addressed, I'm sure on-call engineers will thank you, this work addresses real operating issues.
Hi, I'm the lead engineer for Traffic Control. Glad to see it back in the news! If anyone's interested in more detail about how it works, check out https://planetscale.com/blog/behind-the-scenes-how-traffic-c..., or I'm happy to answer questions here.
This is a good example of another thing you get in the box when you simply pay the man.
https://learn.microsoft.com/en-us/sql/relational-databases/r...
and keep paying, and paying, and paying... forever.
I worked for a startup who decided on AzureSQL, the costs means they were reluctant to have too many environments and ones of the same size, and the cpu/memory was below what they would have if they had self hosted a free database.
Potgresql has chosen by many PAAS, SAAS and IAAS companies like Superbase, PlanetScale, Cloudflare and to meet there needs they are producing extensions like this one so it's future is very bright.
Supabase have hired the creator of Vitess for example and are making Vitess for Postgresql and making it open source https://supabase.com/blog/multigres-vitess-for-postgres
enjoy your closed source bills.
We know about Resource Governor and wanted to bring something as good or better to Postgres. SQL Server classifies whole sessions into a budget. Traffic Control classifies individual queries instead. That's better granularity, especially when a pooler multiplexes multiple different workloads into a session. It also opens up more flexible classification, e.g., based on query plan or based on sqlcommenter tags carrying information about client apps, job queues, priority levels, or release versions.