T-Winsnes

SAML allows you to send additional attributes with the identity payload, like group memberships. This is not inherently authorisation, but can be used to automatically map users to teams/groups/roles in your application.

SAML is a very complicated standard, and very painful to implement. OIDC is much simpler, but lacks some of the capabilities.

Both can automatically create users on login, that is application implementation detail. Both also need SCIM or something similar to offboard users

I had the same thought, I got an alias set up in my ~/.gitconfig to clean up branches that gets deleted from remote when I'm ready

`gone = !git branch -vv | awk '/: gone]/{print $1}' | xargs git branch -D`

Huh, socialism as a violent ideology was not on my bingo card for 2025

I think the right balance here is to have ownership of the outcome rather than the thing. E.g. you have ownership of making sure the feature you’re working on makes it to production and works properly

With that ownership comes there responsibility and accountability of making sure it happens. The level of responsibility and autonomy that comes with that is what I’ve found people react positively to

For basic auth it works well, but the challenge comes when you need to integrate with oidc, need to enforce mfa, enable sso etc. session invalidation is also quite complicated.

You need an identity middle man in front of the Postgres identity to tackle these and validate that the session is still active. Last time I looked at electric it was a big challenge to integrate such a service. This might have improved since then however

The security model is challenging, as it relies on Postgres users for iam. Your users essentially log directly into your db

I think you underestimate the value of controlling the platform that you base all your revenue from. Chrome controls the internet and android has a huge market share on mobile.

The latest changes to chrome that breaks plugins like ublock origin allows them to keep maximising their advertising revenue.

I think these two being open source is a major reason why they have been so successfully adopted. It isn’t direct revenue, but the control and indirect revenue that comes from that which is the driver

I think it comes down to which type of market you’re in. In some markets, like highly congested markets, design makes a big difference. It can be less important in more niche markets

It would be interesting to see if these clusters are related to resource distribution (blood vessels) like how cities often grew up around rivers

We're going through this right now with hava.io

AWS RDS postgress 11.13 > 15.5

We ended up going with a relatively straight forward approach of unidirectional replication using pglogical. We have some experience doing the same migration from Google Cloud sql to AWS rds with zero downtime as well, which made us pretty confident that this will work and not impact customers in any visible way.

pglogical makes it relatively straight forwards to do this kind of migration. It's not always fast, but if you're happy with waiting for a few days while it gradually replicates the full database across to the new instances.

For us it gave us a bit more freedom in changing the storage type and size which was more difficult to do with some of the alternative approaches. We had oversized our storage to get more iops, so we wanted to change storage type as well as reducing the size of the storage, which meant we couldn't do the simple restore from a snapshot.

We’ve taken a different approach with hava.io, why draw yourself when you can automatically draw what’s in your cloud environment.