Live data from Hacker News

Ask HN: Largest Postgres DBs?

news.ycombinator.com

11–18 of 18 posts

Re: Ask HN: Largest Postgres DBs?

#11
post #6

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.

Check out Hydra for Postgres, its an extension to create columnar tables for data warehouse type of analytics. Disclaimer: I’m associated with them as they sell managed services, but the extension is open source.

Re: Ask HN: Largest Postgres DBs?

#13
post #4

I 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…

When you say 'analytics database', what kind of performance are you implying? Massive queries that respond in 10min? How tuned were things for the queries you were running?

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?

#14
post #4

I 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…

Please share the details of the MySQL ones!

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?

#15
post #7

I really would like to know details on how people backup, dump, migrate and upgrade DBs of this size.

Incrementally usually :)

Yes, but a usual pattern for smaller DBs is, for example, to run a full backup weekly and then daily incremental backups. Also, SQL dumps makes easier to do partial recovery, like for a single table.

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?

#16
A few years ago, I used to run and maintain a block explorer that indexed Bitcoin mainnet, in the end, this turned out to be a ~2 TB database which was too expensive to host on any managed database, hence, I ended up running it on the same server that exposed the API.

I 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.

Post reply on HN