5 ms·

I tend to agree with this. AWS etc is nice if your scale is big enough that you need to run a big cloud of dozens of servers with complex interconnections for s

by ufmace 5y ago

I tend to agree with this. AWS etc is nice if your scale is big enough that you need to run a big cloud of dozens of servers with complex interconnections for security etc. If a single plain old server with database etc on it will do the job fine, much better to stick with that.

Daishiman 5y ago
No? A bare metal Postgres install needs optimization, and a working backup and restore plan (you did test your backups, right?). That's half a day of work lost to get your system set up. Now your app keeps serious data and you want a read replica. How long does that take? Now you need a separate development environment. Here you go again, adding a few hours of work. Then you need to update your database version. Gotta read the changelog and make sure you did everything right, and do it in a reaonsable change window. You just racked up several day's worth of work, and for a DB instance with a similar amount of infra work done, the RDS solution is way cheaper and easier to provision. If your time is worth money, there's no reason to go bare metal.
- ufmace 5y ago
  I still disagree and say yes. Why does my bare metal Postgres install need optimization? My sites mostly doesn't get much traffic, and it runs fine as-is. It'd be silly to try and optimize it without being able to measure what's actually slow. Backup systems should also be set up according to desired reliability. I have a 10-line bash script that pulls a DB dump, zips it, and sends it to S3. Under 5 minutes to install, including setting up a new AWS role and keypair for it, just have to add in some Ansible commands I already have set up, and set a cron job to run once a day. Read replicas are nice for some applications, but not needed for any of my current ones. I probably wouldn't want to set one up on bare-metal admittedly, but I'm not worrying about it until I need it. I don't see a need for a separate cloud deployment for a development environment for my current application either. Would be nice if I had multiple developers and testers working on it, but I don't now. Never needed to update the DB version, and the traffic is low enough that I don't need to really care about keeping reasonable change windows if I did. So nope, 10 minutes of work for a low-traffic application. Meanwhile, a AWS RDS setup is easy to start, but then you have to muck with security groups, VPCs, permissions, etc to get it working right. That's not necessarily easy if you don't already make use of that stuff.
  - aggrrrh 5y ago
    Probably you should try sqlite. And maintenance will be even easier.
    - ufmace 5y ago
      There's gonna be a lot of judgement calls here, but I think a local Postgres install is the happy medium. A basic local install is super quick and easy to do, and it also has a lot of good scalability options. SQLite is okay as long as you stay small, but it doesn't scale up very well. If I suddenly get big and my database is Postgres, then I can spin up my own dedicated server, or switch over to RDS after all, optimize concurrent queries, hire a DBA with scaling expertise, etc. Most of that isn't an option with SQLite. I'd have to switch to a completely different database engine. Despite the promises from ORM writers, I've never seen this go smoothly, and it would have to be done at the worst possible time for it.
- yjftsjthsd-h 5y ago
  > Then you need to update your database version. Gotta read the changelog and make sure you did everything right, and do it in a reaonsable change window. What, as opposed to needing to read the RDS patch notes, and schedule the maintenance widow?
  - Daishiman 5y ago
    You might need to read the Postgres version changes for your internal databse code, but you're not gonna need to devise and execute a procedure for upgrading your database, which is essentially done with a single click in an unsupervised manner.

by ufmace 5y ago

Daishiman 5y ago

No? A bare metal Postgres install needs optimization, and a working backup and restore plan (you did test your backups, right?). That's half a day of work lost to get your system set up. Now your app keeps serious data and you want a read replica. How long does that take? Now you need a separate development environment. Here you go again, adding a few hours of work. Then you need to update your database version. Gotta read the changelog and make sure you did everything right, and do it in a reaonsable change window. You just racked up several day's worth of work, and for a DB instance with a similar amount of infra work done, the RDS solution is way cheaper and easier to provision. If your time is worth money, there's no reason to go bare metal.

ufmace 5y ago
I still disagree and say yes. Why does my bare metal Postgres install need optimization? My sites mostly doesn't get much traffic, and it runs fine as-is. It'd be silly to try and optimize it without being able to measure what's actually slow. Backup systems should also be set up according to desired reliability. I have a 10-line bash script that pulls a DB dump, zips it, and sends it to S3. Under 5 minutes to install, including setting up a new AWS role and keypair for it, just have to add in some Ansible commands I already have set up, and set a cron job to run once a day. Read replicas are nice for some applications, but not needed for any of my current ones. I probably wouldn't want to set one up on bare-metal admittedly, but I'm not worrying about it until I need it. I don't see a need for a separate cloud deployment for a development environment for my current application either. Would be nice if I had multiple developers and testers working on it, but I don't now. Never needed to update the DB version, and the traffic is low enough that I don't need to really care about keeping reasonable change windows if I did. So nope, 10 minutes of work for a low-traffic application. Meanwhile, a AWS RDS setup is easy to start, but then you have to muck with security groups, VPCs, permissions, etc to get it working right. That's not necessarily easy if you don't already make use of that stuff.
- aggrrrh 5y ago
  Probably you should try sqlite. And maintenance will be even easier.
  - ufmace 5y ago
    There's gonna be a lot of judgement calls here, but I think a local Postgres install is the happy medium. A basic local install is super quick and easy to do, and it also has a lot of good scalability options. SQLite is okay as long as you stay small, but it doesn't scale up very well. If I suddenly get big and my database is Postgres, then I can spin up my own dedicated server, or switch over to RDS after all, optimize concurrent queries, hire a DBA with scaling expertise, etc. Most of that isn't an option with SQLite. I'd have to switch to a completely different database engine. Despite the promises from ORM writers, I've never seen this go smoothly, and it would have to be done at the worst possible time for it.
yjftsjthsd-h 5y ago
> Then you need to update your database version. Gotta read the changelog and make sure you did everything right, and do it in a reaonsable change window. What, as opposed to needing to read the RDS patch notes, and schedule the maintenance widow?
- Daishiman 5y ago
  You might need to read the Postgres version changes for your internal databse code, but you're not gonna need to devise and execute a procedure for upgrading your database, which is essentially done with a single click in an unsupervised manner.