I have a +1tb Postgres database at home that has market data in it. Moving it over to another Postgres db that has timeseries extensions to compact and increase performance. Also thinking about just partitioning everything up into parquet files. Query performance isn’t the best and am currently trying to improve it.
Ask HN: Largest Postgres DBs?
11–18 of 18 posts
Re: Ask HN: Largest Postgres DBs?
#12And that was in _2018_. I wonder how big it is now.
Re: Ask HN: Largest Postgres DBs?
#13I have more experience running large MySQL databases. Both at SurveyMonkey and Zapier our primary databases were MySQL and were massive as you can imagine from massively scaled consumer products. I won't list the data here since this is about postgres but wanted to provide the context. The largest postgres I've personally administered is on RDS: * postgres 13.4 * db.m6g.2xlarge (8vCPU, 32 GB RAM) * 1.3tb storage * La…
I'm currently working through an analytics architecture and I'm having to defend against "why aren't you using postgres" when I'm talking about olap dbs.
Re: Ask HN: Largest Postgres DBs?
#14I have more experience running large MySQL databases. Both at SurveyMonkey and Zapier our primary databases were MySQL and were massive as you can imagine from massively scaled consumer products. I won't list the data here since this is about postgres but wanted to provide the context. The largest postgres I've personally administered is on RDS: * postgres 13.4 * db.m6g.2xlarge (8vCPU, 32 GB RAM) * 1.3tb storage * La…
I said "postgres" because I didn't want to say "SQL" and include crazy systems with SQL query interfaces.
Re: Ask HN: Largest Postgres DBs?
#15I really would like to know details on how people backup, dump, migrate and upgrade DBs of this size.
Incrementally usually :)
On this size class (~1TB) I see PITR backups using something like Barman as the only viable alternative. (Of course you can also copy the whole VM/Disk etc)
Re: Ask HN: Largest Postgres DBs?
#16I remember when I had to run this for the first time, I faced a few challenges, for example:
- I usually don't care about optimizing the db schema because postgres can handle most projects without much effort, this wasn't the case anymore, there were indexes that I had to drop because these were causing inserts to become considerably slower and they took a few GB to store them.
- Column types started to matter, I had some columns that were stored as hex-strings but I ended up switching to BYTEA to save some space.
- The reads were slow until I updated the postgres settings, postgres default settings are very conservative and while they can work for many projects, those won't work when you have TB of data.
- While this isn't database specific, offset-pagination does not work anymore and I switched all of these queries to scroll-based pagination.
- Applying database migrations isn't trivial anymore because the some operations could lock the database for hours, for example, updating a column type from TEXT to BYTEA isn't an option if you want to avoid many hours of downtime, instead, you have to create a new column and migrate the rows in the background, once the migration is ready, drop the old column.
Overall, it was a fun journey that required many tries to get a decent performance. There are some other details to consider but it's been a few years since I did this.