But you’ll need a powerful system with 64GB of RAM to use it.
Microslop thinks that “Clutter free” means “bundled with an always on LLM” 😸
But you’ll need a powerful system with 64GB of RAM to use it.
Microslop thinks that “Clutter free” means “bundled with an always on LLM” 😸
I got the same impression. That dev work isn’t power hungry, just the stack is. But if IT controls the stack, that explains some of the dilemma.
Why an RDBMS on the local though? Testing shit doesn’t make sense to name it as a regular piece of software.
When you work on backend services you have a local DB running 24/7. Changes don’t go onto the actual dev environment until locally tested, or you might just break things for 50 other people.
I always build against a local DB?
For our desktop / LAN software the DB will always be local.
For web, it’s easier since I’m likely to burn the DB down over and over during early development / prototyping. But I’m not using cloud hosted DB even in production, and don’t expose Postgres outside the DB server, so I find it easier to work on this way.
EDIT: I also think that a default installation of VS includes SQL Server. I don’t use it, so always have to adjust the installation and remove all of those bits, but I also have complete control of my environment. I could see an IT department just doing a stock VS installation with the required workloads.
Yeah sorry, that’s what I meant by testing stuff. I suppose if you’re always testing things in the DB, it makes sense. Usually in my case, I would spin up a Postgres instance only for the week or so that I’m developing and testing with it. Eventually I push to cloud though. I don’t keep it running locally unless I’m testing a change. But I’m not testing changes often… I wouldn’t consider it part of my stack for that reason. I might run a local RDBMS a few times a year.
On the other hand, I will use SQLite or DuckDB all the time for local work. Not sure if those count as RDBMS, they are serverless.
I won’t never consider a local RDBMS as having stable data storage, so it falls into a strictly “testing” category for me, I guess “development and testing” is more accurate.
I could totally see that for the web stuff where I only make changes a couple of times a year. Usually when working on those I just delete the local DB before I start to keep it clean, but spinning up a new copy would be more efficient.
For our desktop apps / server Postgres is always installed locally on the machine, so keeping it there mirrors “production”.
I spent most of my time working on those apps and services, or working on the Android client (or both at the same time when a feature requires that both change), and often on a copy of actual customer data as we do a lot of custom work for clients.
Yeah, that’s exactly the process- while you are building out a feature it hits a local DB and once it’s ready to integrate you push it to a shared environment.
If you break dev, coworkers be mad