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 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