> Even low-risk fixes like renaming a database column can break a billing run when a job is currently using that data.
You should tell me how you rename database columns in AWS without breaking anything.
I’m not really sure what the point of this article is, it just seems to promote the company’s migration method with a misleading title. But I highly disagree that self-hosted is harder. With many self-hosted BaaS systems I’d argue it’s easier.
The strange part: In my experience, this is easier at a single-tenant/single-customer on-prem system than in AWS / a multi-tenant hosting.
On-Prem, the operations team can announce: Hey, System XYZ won't be available Saturday Morning in two weeks due to an upgrade. Then you shutdown the entire thing, change the column name and start it back up on a new version. I've had a few chats with system responsible people at customers even for very large customer support organizations - to them, a well coordinated and controlled downtime is something they can just work around and it might even be preferable over a more complex, less controlled maintenance without downtime.
In our own hosting, the more complex migration procedure would be easier to coordinate and execute though, than coordinating such a downtime with a lot of customers.
> a well coordinated and controlled downtime is something they can just work around and it might even be preferable over a more complex, less controlled maintenance without downtime.
It is generally the case that preventative maintenance is orders of magnitude cheaper than break fix maintenance. If you have the luxury of bringing entire systems down routinely, you are much more likely to engage in the first kind.
Agreed on both counts - absolutely awful article, and self-hosting is not hard. You seemingly need a phd to do the most basic things on AWS
People argue self-hosting is insecure, then open up their AWS RDS instance to the whole world because they can't figure out their IAM settings.
It makes sense that someone who thinks that clouds are magically secure will fail to take the steps to make a cloud configuration secure.
I didnt read the article but how you do is, you should create new column without deleting the old one, and your code should be updated to use the new column, once you phase out the old version of the code, you backfill data from old column to new one, and delete the old column.
Or you rewrite queries on the fly with ProxySQL or similar to use the new column name, and then deploy the new code. Can even insert a momentary pause at the proxy layer so no queries hitting the old name sneak through while you do the rename.
This method doesn’t work as well with distributed DBs, but to be fair they’re a terrible idea for most use cases.
> You should tell me how you rename database columns in AWS without breaking anything.
Intermediate updatable views is one way.
forgive my ignorance, but is that AWS (or, cloud) centric?
I thought that was a RDBMS primitive.
Updatable views are a vanilla Postgres feature