Také mám 300GB+ tabulky v PostgreSQL a jde to. Pokud chápu tazatele, tak má data, co musí naimportovat hromadně 300GB, zpracovat, zahodit a za čas znovu.
Pak bych se zamysle nad tím Postgresem, možná včetně nadstavby TimescaleDB, mohlo by to být rozumně použitelné. Zazněl InfluxDB, tak mám zkušenost, že dávkový import velkého množství dat není žádný rychlík a co jsem se díval, tak podobě to vycházelo u dávkového masivního importu pro Cassandru. U Influxu také dotazy přes větší sady dat dost drhnou (jak to začne de/kompresovat) u toho TimescaleDB by to mohlo být průchodnější při potlačení komprese. Nebo použít navrhované partišny po nějakém časovém bloku, pokud nechci do toho PgSQL tahat TimescaleDB.
Určitě to dost ovlivní indexy, nevhodně složitý trvá pak jeho sestavneí a žere dost místa. U takovéto jendorázové operace by se mohl hodit hash index, sestavoval se rychleji a zabíral méně místa, než klasické btree (a zlomek třeba proti gist), ale nevím jak poslední verze PgSQL, dříve (do PgSQL10) nebyl spolehlivý z pohledu nutnosti reindexace po restartu DB, ale pokud celé zpracování proběhne během jednoho běhu DB a nepotřebuji vlastnosti, co hash index nemá (nepodporuju unique, vícesloupcový index, sorted index a možná ještě něco), tak by mohl pomoci s urychlením.
A pokud jde o časové řady a imporutji data, co jsou už relativně utříděné (což je urychlení vždy), tak i brin indexy pomohly.