You can adopt a centralized system. And it's fashionable to do so. Lots of people here and other places advocate doing everything you can on the server.
But it's not required. Additionally, there are plenty of good incentives not to, including cost. Client CPUs are fast, free to use, and don't require a high latency network hop. Local ram, disk, and network transfer are also available in abundance. You can totally reverse the architecture where the client is doing the heavy lifting and provide the user a good experience.
Intel CPUs are inefficient when pegged, but more efficient at idle. On AMD your using the same cores the cloud is. Without the massive IO attached on the server side the client CPUs are more efficient for a unit of work. Apple is more efficient than the PC side presently, and Qualcomm is entering the fray and appears to be quite efficient.
So I'm really not certain where you're efficiency claim about client hardware comes from. All that hardware is just sitting there and sales vary, but they are not cratering for high performance local compute.
You have a point about GPUs, but only a very few very specialized applications need those.
What's nice about Postgres is there's a ton of Postgres compatible products that do scale for the 10% who actually need it. And it's still all just Postgres / SQL.
Nosql is a fun target to beat up on of late. But there are good, even infamous, reasons to avoid SQL. Particular if you want to accomplish flexible record queries from untrusted clients.
All you do is poop all over the story about postgres. I'm convinced that no use cases will convince you of anything. I'm not really looking to involve myself in a database holy war.
Is jsonb in Postgres not flexible enough? I dump external json in there all the time (like large API responses). The jsonb operators work well. And there's an escape hatch that lets you easily convert json to a table. And importantly, you get indexes with Postgres.
Might I suggest you actually use mongo on a project before engaging further on the topic. It clearly has had a lot more thought put into it in the context of json documents.
If postgres works great for your use cases, great, go be happy with the tool.
Definitely a better solution than the brick wall he hit. Complicated beastie. I can see the appeal if you just love, eat, and breath SQL.
But a query language within a query language feels bolted onto something alien to do something pretty basic. Pass. If I'm teaching this to new engineers, pass also.
> True, but SaaS still runs on cloud infrastructure so the costs are still there
You can bring the costs way down. Their margins include a pretty insane amount of features that not everyone needs. There is a lot of meat there if you have skills in the area.
Making/saving money via DIY compute is an area ripe for improvement via better vertical integration.
The big cloud providers simply do not have this market cornered even with this mind share that prevents perfectly good engineers from seeing the path plain before them.
There is a place for religion. Something that pushes you to be better than you are. Along with the happiness and fulfillment that comes from that effort. Selflessness, love, compassion, truth.
Plenty of bad religions telling you that you are perfect the way that you are. Just give me money, fame, or influence and I will flatter you and pump your ego.
Another form of this is flattery in exchange for hating something. Many doomsday cults fit this category. All your life problems are because of 'insert target X'. But I, I have the answers you need.
Religion is more attuned with purpose, where your heart is, than the belief in God. Though the two are often paired.
There are plenty of things that deliver the above without the dogmatic slaughter of hundreds of millions of humans throughout history and at this very moment.
There's also plenty of religious people who have never murdered anyone in their lives, and there have been plenty of dogmatic massacres for reasons entirely unrelated to religion. The two issues seem to be quite uncorrelated tbh.
Religion requires belief without evidence. (Or flimsy evidence like ancient testimony.) It's uniquely positioned as a tool to manipulate people to do things they wouldn't otherwise do.
The project sounds successful overall to me. Yes, they had to do more than they thought going in. That describes most engineering efforts.
Does the author think that operating system API churn just won't affect native somehow? Or be improved when even more of your application surface area is in the native space?
If stuck with consumer drives, you can add cheap PLP via riser cards that have a supercapacitor. Here's a post on the TrueNAS forums that tested one out.[1]
But it's not required. Additionally, there are plenty of good incentives not to, including cost. Client CPUs are fast, free to use, and don't require a high latency network hop. Local ram, disk, and network transfer are also available in abundance. You can totally reverse the architecture where the client is doing the heavy lifting and provide the user a good experience.
Intel CPUs are inefficient when pegged, but more efficient at idle. On AMD your using the same cores the cloud is. Without the massive IO attached on the server side the client CPUs are more efficient for a unit of work. Apple is more efficient than the PC side presently, and Qualcomm is entering the fray and appears to be quite efficient.
So I'm really not certain where you're efficiency claim about client hardware comes from. All that hardware is just sitting there and sales vary, but they are not cratering for high performance local compute.
You have a point about GPUs, but only a very few very specialized applications need those.