Using a tool like diskplorer (mentioned in article 1) to gather the concurrency and IOPS relations at various read sizes (mentioned in article 2) seems like it a good datapoint for use in tuning a database filesystem. https://github.com/avikivity/diskplorer

As long as you turn a PG table into a BQ dataset with enough partitions (BQ tables) such that queries do not touch a disproportionate amount of unnecessary data, you utilize date partitioning, and you can deal with a minimum 1.5 second query time the service is truly amazing. My only frustrations are that the majority of streaming service degradations are never noted on the Status dashboard and that you can get really odd error states like headers stating that you should be getting json while the body contains a html error message.

If the rebalancer leverages an update from PostgreSQL 10 does that mean new Citus formations are now PG10 based?

Yep, newly created formations on Citus Cloud will be PG10 and the latest version of Citus. For any existing customers on PG 9.6 and older versions of Citus we'll be upgrading those that opt in. Our upgrade process leverages our underlying disaster recovery and high availability infrastructure[1] so we can generally upgrade an entire cluster regardless of data size in under a couple of minutes.

[1] https://www.citusdata.com/blog/2017/03/23/a-look-into-disast...

Looking through the public Grafana dashboards I noticed that the database backups page is not showing any data points (http://monitor.gitlab.net/dashboard/db/backups). Is this meant to a public page?

This is meant to be a public page. It loads async. After 3 seconds I see the following https://www.dropbox.com/s/5mt5f77e60yogk1/Screenshot%202017-...

There was an issue with the dashboard causing it to try and load data from the wrong place, this has been fixed. See https://gitlab.com/gitlab-com/infrastructure/issues/3115 for more info.