No processing done at the DB very often implies more queries and consequently a higher workload in the DB than just doing the processing there. That's evident when looking at typical ORM usage (usually very chatty applications).
Also very often doing the work in the DB means a simpler solution, fewer race-condition issues, and less work overall.
When talking about this particular case, the CHECK constraint, it is probably matter of measuring the impact and understanding at which point this might be relevant, and considering the cost of the alternative implementation at the application layer
You could easily create a new revision of the function you want to change, and have the first box to use the new revision while the rest keep using the old one.
In postgres that would be trivial with revision schemas and a clever usage of the SEARCH_PATH.
Sure, it works for a narrow use-case like a pure function that just queries and returns data. What about stored procedures/triggers that mutate data on insert/delete etc?
With one-box, you can assign a specific set of customers/canaries to be served by the new 1-box and validate your results. If there is a problem you rollback and only your canary data was affected. It is just not very simple IMO.
That is a neat idea. I was sort of thinking of that, but was concerned about invalid and unused database objects.
You'd avoid name collisions pretty handily, though. I'm guessing that you would just need some policy to drop all of the old versions after some period.
You'd also just need to bundle grant exec statements with the procedure DDL.
That would work well with Oracle and DB2 as well. I'm not totally sure about SQL Server, though.
I disagree here, Elixir looks similar to Ruby from a syntax perspective. But as soon as you dig into OTP it is a completely new world.
It's true that as a beginner you can simply do web development with Phoenix and that feels similar to Rails (Or Django / Laravel / Spring / whatever web framework ). But OTP requires a different way of approaching problems.
I don't think Go or Rust provides anything similar to what you have in Erlang/Elixir. I've done a lot of Ruby and then while learning Haskell and Elm has been a paradigm change with their type systems, Elixir/Erlang felt like a much bigger step in terms of a different required way of approaching problems.
It's not that it's functional (that's completely secondary in Erlang) but its fault tolerance primitives (processes, pids, mailboxes, monitors and links) and the OTP abstractions (GenServers, Supervisors, etc).
You learn to think in terms of distributed systems and think about fault tolerance in a way you cannot in other languages as they don't provide the primitives. It's quite a big leap and it takes time to sink in.
Toon Koppelaars shows that in a few experiments done with Oracle ( https://www.youtube.com/watch?v=8jiJDflpw4Y&ab_channel=Oracl... )
Also very often doing the work in the DB means a simpler solution, fewer race-condition issues, and less work overall.
When talking about this particular case, the CHECK constraint, it is probably matter of measuring the impact and understanding at which point this might be relevant, and considering the cost of the alternative implementation at the application layer