Live data from Hacker News

Mastering PostgreSQL Administration [pdf]

momjian.us

11–20 of 56 posts

Re: Mastering PostgreSQL Administration [pdf]

#11
post #7

I debated running my own Postgres cluster for a side project, but ended up paying for Digitalocean’s managed offering. I’d like to hear from anyone running their own Postgres. Why did you choose to do that vs pay for a managed instance? How much of a hassle has it been? Is it something you really need significant Postgres experience to do well (to achieve security, backups, high availability, etc)? Biggest gotchas to…

Most managed offerings run on virtual machines where performance is 1/10th of what you'd get on a bare-metal machine rented for the same cost. As an example, I'm currently working on a project where we have an Azure managed Postgres DB for a staging environment. It costs ~50$/month and is an order of magnitude slower than my entry-level MacBook. That amount of money would give you fast NVME storage, 8 core dedicated…

This too was our experience. We had several clusters running on one of the managed services. The cost didn't justify what we could do with running it ourselves.

We're lucky to have experience with Postgres, performing backups (of the various types) and restoring DBs on production environments. We don't have things automated, but that would be next.

I think startups are hard to do it in-house, not for a lack of expertise (or willingness to get it), but the fact that there are already so many things to handle.

Re: Mastering PostgreSQL Administration [pdf]

#12

I debated running my own Postgres cluster for a side project, but ended up paying for Digitalocean’s managed offering. I’d like to hear from anyone running their own Postgres. Why did you choose to do that vs pay for a managed instance? How much of a hassle has it been? Is it something you really need significant Postgres experience to do well (to achieve security, backups, high availability, etc)? Biggest gotchas to…

The first consideration should be backups. This can be pretty easy if your database is small and you're okay with losing a few hours or a day of data if something happens. Then it's simply a matter of having a cron job dumping the database and backing those dumps up via some common backup tool. A proper backup with point-in-time recovery is not that hard to set up, but it does take some time to read up on the topic a…

> The first consideration should be backups.

Useful to look at barman and see if it can meet one's needs:

* https://www.pgbarman.org/

* https://github.com/2ndquadrant-it/barman

No sense re-inventing the wheel if it can be avoided.

Re: Mastering PostgreSQL Administration [pdf]

#14

I debated running my own Postgres cluster for a side project, but ended up paying for Digitalocean’s managed offering. I’d like to hear from anyone running their own Postgres. Why did you choose to do that vs pay for a managed instance? How much of a hassle has it been? Is it something you really need significant Postgres experience to do well (to achieve security, backups, high availability, etc)? Biggest gotchas to…

DB connections are a bit more expensive, so a pool is a must if you get a lot of connections. Back when I used it the HA was also separate but they may have something built-in by now.

Re: Mastering PostgreSQL Administration [pdf]

#15

Earlier quoted context omitted.

The first consideration should be backups. This can be pretty easy if your database is small and you're okay with losing a few hours or a day of data if something happens. Then it's simply a matter of having a cron job dumping the database and backing those dumps up via some common backup tool. A proper backup with point-in-time recovery is not that hard to set up, but it does take some time to read up on the topic a…

> The first consideration should be backups. Useful to look at barman and see if it can meet one's needs: * https://www.pgbarman.org/ * https://github.com/2ndquadrant-it/barman No sense re-inventing the wheel if it can be avoided.

WAL-E/WAL-G are another option if you're looking for PITR.

Re: Mastering PostgreSQL Administration [pdf]

#16

I debated running my own Postgres cluster for a side project, but ended up paying for Digitalocean’s managed offering. I’d like to hear from anyone running their own Postgres. Why did you choose to do that vs pay for a managed instance? How much of a hassle has it been? Is it something you really need significant Postgres experience to do well (to achieve security, backups, high availability, etc)? Biggest gotchas to…

The first consideration should be backups. This can be pretty easy if your database is small and you're okay with losing a few hours or a day of data if something happens. Then it's simply a matter of having a cron job dumping the database and backing those dumps up via some common backup tool. A proper backup with point-in-time recovery is not that hard to set up, but it does take some time to read up on the topic a…

> High availibility is a bit more complicated to set up with Postgres, and I don't have much experience with that part.

There is Patroni[0], which has a Docker-based setup template in Spilo[1]. I don't have expertise enough to say anything about these, except that I've been running an HA setup with Spilo for several months without issues so far.

Would be interesting to hear what more experienced postgres people have to say about it :)

Also we've opted to just use traefik (based on spilo service registration) rather than pgbouncer.

[0]: https://github.com/zalando/patroni

[1]: https://github.com/zalando/spilo

Re: Mastering PostgreSQL Administration [pdf]

#17

I debated running my own Postgres cluster for a side project, but ended up paying for Digitalocean’s managed offering. I’d like to hear from anyone running their own Postgres. Why did you choose to do that vs pay for a managed instance? How much of a hassle has it been? Is it something you really need significant Postgres experience to do well (to achieve security, backups, high availability, etc)? Biggest gotchas to…

Our product offers near real time (incremental sync every 3 mins) backup and restore solution for on-premise SQLServer data. We have used PostgreSQL to store the backup data in cloud and offered add-on services on top of PostgreSQL data (such as reports, analytics, etc). Every customer data is stored as a separate database.

Initially we have used RDS as PostgreSQL instance when the product is in pilot phase. RDS costed us $548 for just 2vCPU 16GB 500GB SSD (db.r5.large Multi-AZ). Considering the increasing active customer base and volume of data involved, we found that RDS is very expensive and costed us more (> 100%) than the market affordable estimated product pricing (:facepalm:). As per our performance benchmark, we found that db.r5.large can accommodate 250 customers and scalable linearly. To reduce the RDS spend, we had to reduce two costs.

1) Reduce the RDS Instance cost / customer - we aggressively optimised our sync flow and final benchmark reveals 500 customers can be accommodated in db.r5.large Instance (50% less RDS Instance spend / customer)

2) Reduce the RDS Storage cost / GB of customer data - we could not find any way to reduce the storage cost. Since RDS Instance is fully managed by AWS, no possibility of data compression.

When we compared the total cost based on our usage, RDS Instance cost is just 10-20% and Storage cost is 80-90%. So finally we decided to host our PostgreSQL Instance in EC2 with transparent data compression. This is our current configuration and usage metrics.

r5a.xlarge (4vCPU 32GB)

PG Master - Availabilty Zone 1

PG Slave - Availabilty Zone 2 (Streaming Replication)

----

8 x 100GB ZFS RAID0 FileSystem with LZ4 Compression (128KB recordsize)

40GB (wal files) ZFS FileSystem with LZ4 Compression (1MB recordsize)

600GB Compressed Data (3.1TB Uncompressed - x5.18 compression ratio)

----

2 x r5a.xlarge - 2 x $104.68 = $209.36

2 x 8 x 100GB - 2 x 8 x $11.40 = $182.40

2 x 40GB - 2 x $4.56 = $9.12

Total EC2 Cost = $400.88

----

If we had to use RDS

db.r5.xlarge Multi-AZ = $834.48

3.5TB Multi-AZ = $917.00

Total RDS Cost = $1751.48

----

So we have reduced our cost by $1751.48 / month (greater than x4 times) by using EC2 instead of RDS. Best of all we have purchased 3 Years No Upfront Savings Plan which further reduced our EC2 Instance cost to $105 (50% reduction). RDS doesn't have No Upfront Reserved plan for 3 Years and for 1 Year No Upfront we get just 32% Instance cost reduction.

Apart from the direct EC2 Instance cost and Storage size reduction, major benefit we indirectly got by migrating to EC2 Instances is

- IO Throughput increased by x5 due to ZFS LZ4 Compression. Importing of 3GB Compressed GZIP file would take around 2.5 - 3 hrs in RDS whereas in EC2 it just takes 30 - 45 min.

- Existing Savings Plan discount automatically applied (50% reduction)

- Ability to migrate to AMD based Instances (r5a.xlarge) - 50% reduction compared to Intel based Instances (r5.xlarge) in Mumbai region. It'll take ages before AMD based Instances are available in RDS.

- Ridiculous EBS Burst Credits by using 8 Volumes in RAID0. Base IOPS - 8 x 300 (100GB) = 2400 IOPS. Burst IOPS Credits - 8 x 3000 = 24000 IOPS :D

- PG Master is used for backup sync write operations and PG Slave is used for reporting and analytics. RDS requires Read Replica to be created from the already existing db.r5.xlarge Multi-AZ Instance for read operation which will further increase the estimated RDS cost by x1.5

- Planning to migrate to AWS Graviton 2 ARM64 Instances. AMD (r5a.xlarge) and Intel (r5.xlarge) based Instances have hyperthreading enabled which leaves us with just 2 real cores and 4 threads. But basic Graviton 2 Instance r6g.large itself has 2 real cores. So I'm kinda estimating that the basic r6g.large (2vCPU 16GB) Instance itself can support upto 1000 Active Customers (further 50% EC2 Instance Cost reduction).

Re: Mastering PostgreSQL Administration [pdf]

#18

Earlier quoted context omitted.

The first consideration should be backups. This can be pretty easy if your database is small and you're okay with losing a few hours or a day of data if something happens. Then it's simply a matter of having a cron job dumping the database and backing those dumps up via some common backup tool. A proper backup with point-in-time recovery is not that hard to set up, but it does take some time to read up on the topic a…

> The first consideration should be backups. Useful to look at barman and see if it can meet one's needs: * https://www.pgbarman.org/ * https://github.com/2ndquadrant-it/barman No sense re-inventing the wheel if it can be avoided.

I've been very satisfied with Barman. I considered a variety of backup options including replication. Barman is a good alternative to replication if you can tolerate a small mount of downtime while you restore. For us, it takes less than 15 minutes to provision a new VM and restore from Barman. I’m ok with that downtime because it simplifies operations by eliminating the need to operate a secondary database sever and manage replication.

Also, Barman offers point-in time recovery (PITR).

Lastly, we do a nightly logical dump which gets uploaded to a bucket (located at another cloud service).

Re: Mastering PostgreSQL Administration [pdf]

#19
post #7

I debated running my own Postgres cluster for a side project, but ended up paying for Digitalocean’s managed offering. I’d like to hear from anyone running their own Postgres. Why did you choose to do that vs pay for a managed instance? How much of a hassle has it been? Is it something you really need significant Postgres experience to do well (to achieve security, backups, high availability, etc)? Biggest gotchas to…

Most managed offerings run on virtual machines where performance is 1/10th of what you'd get on a bare-metal machine rented for the same cost. As an example, I'm currently working on a project where we have an Azure managed Postgres DB for a staging environment. It costs ~50$/month and is an order of magnitude slower than my entry-level MacBook. That amount of money would give you fast NVME storage, 8 core dedicated…

First time I'm hearing about soyoustart. I've been under the assumption that Linode's instances are the cheapest ones, but the one you linked is Can you share your experience with using soyoustart?

Re: Mastering PostgreSQL Administration [pdf]

#20
post #19
post #7

Earlier quoted context omitted.

Most managed offerings run on virtual machines where performance is 1/10th of what you'd get on a bare-metal machine rented for the same cost. As an example, I'm currently working on a project where we have an Azure managed Postgres DB for a staging environment. It costs ~50$/month and is an order of magnitude slower than my entry-level MacBook. That amount of money would give you fast NVME storage, 8 core dedicated…

First time I'm hearing about soyoustart. I've been under the assumption that Linode's instances are the cheapest ones, but the one you linked is Can you share your experience with using soyoustart?

SYS is basically OVH’s lower-end offering that still provides SLAs and better bandwidth (they have an even cheaper offering called Kimsufi but no SLA on those - though great value for staging/non-critical systems).

The experience is mostly solid, though they don’t provide any kind of console access and I once got locked out after putting a machine to sleep from the command line (and had to open a ticket for someone to reboot it manually).

The "problem" is that this is not a virtual machine and most assumptions or ways of thinking that work for AWS or similar don't work here. For example, you can't just upload an image or move data volumes around between machines. The storage volume is a physical disk attached to the machine, if you need to copy them you need to actually boot the machine, SSH into it and do your thing. Similarly, those disks can break down and you need to plan ahead (they provide 2 disks per machine and expect you to use a software RAID 1 or have a backup/restore strategy that can tolerate those disks failing).

This is where building your own layer on top of it (whether Kubernetes or VMWare or similar) makes sense and will make your life easier and allow you to use most tools we take for granted when it comes to VM providers - you're essentially building your own AWS.

This is a whole other league compared to Linode - the former provides VM instances with varying levels of performance - the one we’re talking about is bare-metal and you are guaranteed to have the performance of whatever hardware specs you chose. Bandwidth is also unmetered so you can saturate the pipe 24/7 if you wanted to. Very cost-effective for serving media, though every machine only comes with 250Mbps, so maybe it's better to have an origin server on SYS, and lots of downstream instances on Kimsufi which serve as a downstream cache for the origin - they are dirt-cheap and come with 100Mbps bandwidth each (unmetered as well).

Post reply on HN