undefined@undefined@lemmy.hogru.ch

Replying to @⁨Vlyn@lemmy.zip⁩

Teams, Visual Studio, VS Code are trash, they leak memory like no other

WSL2 is hilarious, just run Linux/UNIX?

SQL Server and SSMS are trash

I run Docker quite a bit but if you’re actually writing the containers efficiently it shouldn’t be sucking down ~64GB of RAM. But I’ve also seen how people shovel things like Java, log rotation, etc. into those containers because they act like it’s a 1994 VPS.

hdsrob@hdsrob@lemmy.world
edited

Replying to @⁨partofthevoice@lemmy.zip⁩

Why an RDBMS on the local though? Testing shit doesn’t make sense to name it as a regular piece of software.

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.

partofthevoice@partofthevoice@lemmy.zip

Replying to @⁨hdsrob@lemmy.world⁩

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.

Edited ⁨⁨Sep⁩ ⁨6⁩, ⁨2026⁩, ⁨17:35⁩⁩en
hdsrob@hdsrob@lemmy.world

Replying to @⁨partofthevoice@lemmy.zip⁩

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.