For most folks autovacuum "Just Works", transparently and in the background. For people with large volumes of UPSERTs or similar workloads with lots of activity against existing rows, it may be necessary to tune autovacuum - usually to be more aggressive than the defaults. Aside from figuring out that this is a thing that can be done and then doing it (or paying someone to figure this out for you), there really isn't much operational burden involved.
I have seen cases where it made sense to run regularly scheduled vacuums outside of just leaving it all to autovacuum, but in my experience this is rare - when I see someone worrying about vacuums it's usually the case that they should just change an autovacuum knob and then forget about it.
(Disclaimer: I was at Heroku from Jan 2019 - July 2022, supporting Heroku Data products for most of that time. I have no special insight into this latest news beyond what's being reported publicly.)
> We host a lot of individual apps, many that only need free tier DBs and Redis.
I saw a lot of this, and while it's certainly not abuse it was - to my mind - a failure to turn Heroku's multi-tenant DB services into a real product.
Obviously it's not free to provide free services, but because they are "free" they don't get the same treatment and respect. Over time, these free or "hobby" services end up underpinning real production workloads such as SaaS providers using them for low-usage tenants of their own services, or for critical infrastructure stuff like review apps.
Tons of work goes into making those hobby redis and postgres plans work smoothly, abstracting away the complexity involved. If only someone were to put a customer-facing UI and API in front of that, and charge for it - so that you could pay one fixed price for a service that let you host as many DB tenants as you can fit on it, isolated from any other customers? It wouldn't be free, but it would be a killer feature.
It's a pity I don't see anything like that on the roadmap! Oh well, maybe someone else will do it first.
I agree. I support paying for everything because everything has a cost. But I also think the amount I pay should reflect the cost it takes to run the service and the value I get out of it. We do not get $15/m in value out of the $15/m tier of redis for most of our apps. A multi-tenant solution that costs us something like $1/m per app would be much more reasonable.
I've been working remotely for ten years, in a city with a very small but friendly tech scene. A lack of local meetups doesn't always indicate that there's no tech scene, either - when I first started working remotely I was the only person I knew who was doing it, but just by being vocal about it I quickly found others. If there are no meetups in your field then starting one is a brilliant way to tick a bunch of boxes here:
- You will bring people out of the woodwork who are in similar positions, but haven't taken the initiative to start such a group themselves.
- You'll gain contacts in your scene, both locally and in other cities.
- You'll gain experience and profile that will help you in a search for remote work, as you can point to community engagement activities that say a lot more about your dedication than a couple of udemy courses in some particular stack.
If you really don't want to start a local group (or if there's no nearby community large enough to support this) then look for user groups with active online communities (mailing lists definitely count) and try to make some occasional trips to other cities for meetups and conferences.
> Despite being an obvious usability hole, this has never been fixed.
Well, which implementation of make should be fixed? The thing about these truly ubiquitous nix tools is that eventually people discover that there are unixes other than Linux.
That's true, but it also leads to bloated special purpose tools that take minutes to run, as described in the introduction of the article.
Sometimes you've better off having something that does exactly what you need, regardless of speed. Sometimes you need something fast, lightweight, ubiquitous, and reliable despite its quirks.
I have seen cases where it made sense to run regularly scheduled vacuums outside of just leaving it all to autovacuum, but in my experience this is rare - when I see someone worrying about vacuums it's usually the case that they should just change an autovacuum knob and then forget about it.