Time is money, and my 5+ year old desktop is costing me a heap of it right now. The final straw has come when processing several terabytes of stealer logs which has taken forever. Meanwhile, Stefan has been flying through them with a massive NVMe drive on a fast motherboard.
So, in no particular order, here's what I need it to do:
- Read and write multi-terabyte files fast
- Run SQL Server locally for both development and querying of large data sets (the latter is especially memory intensive)
- Dev environment is largely Visual Studio, SSMS and other (less intensive) tools
- Run a gazillion simultaneous Chrome tabs 😛
And here's my current thinking:
- SSDs (Samsung 9100 PRO?):
- Fast OS drive big enough for Win 11 plus apps
- The biggest possible drive for processing the sorts of files described in the intro
- I'll probably drop an existing 10TB mechanical drive in, purely for storage
- RAM:
- As much as feasible without ridiculous costs (a lot of the data processing is done in-memory)
- Probably don't need pricier ECC memory
- Processor
- I've had Intel but am open to change (Threadripper seems to have got a lot of love lately)
- GPU
- Needs to drive two 2560x1440 screens plus one 5120x1440
- This isn't going to be used for gaming or hash cracking
And before you ask:
- Yes, it will run Windows, not Mac OS or Linux
- No, pushing all this to "the cloud" is not feasible
Suggestions, comments, questions and all else welcome, thanks everyone!




Yeah seems like there's a lot of outages today. Yay everything is cloud!
Anyway: again, really depends on the workload, and specifics of how data is laid out by MSSQL, i.e. if you read by an index, and whether the server reads from random blocks on a HDD, or if it sorts it first by location and reads almost-sequentially - that alone can have mean 50~1000x slowdown just by the nature of HDDs that you would not have even on a same-read-speed SSDs - nevermind that NVMes nowadays have 200x higher throughput/read speeds. So even with the exact same hardware today, just moving to NVMes will speed up some of your workloads literally >100x. I'm sure you know that but it's worth repeating, as someone who had nose deep into io bottlenecks.
If you plan more than 256GB RAM, then most definitely go with Threadripper. However, the price difference is not negligible, and you will NOT use most of the cores most of the time, again by nature of the sql engine / io wait / tasks that cannot be reasonably parallelized. You will get lower single-thread performance, so again, it's good to analyze how many of your current bottlenecks are on single-threaded tasks and see if the slowdown is acceptable. Software will improve and more tasks will be parallelized, but some of them fundamentally can't. Again, sorry for stating the obvious.
If you'll be fine with 256GB RAM, high-end Ryzen can be fine. You'll get slightly faster single-thread performance, and again, not many tasks will benefit from 16 vs 32 physical cores. Do some napkin math of what your data looks like, eg.
Similarly, assuming SQL Server can use most of the RAM as cache (again, as the other person said: double check your license, it might have artificial memory limits), let's say 220GB can be used by either kernel or DBMS cache - that will have 10x higher IO than the ones read from disk - if you know you're using an index to read only 10% of the table, e.g. 400GB, you might get to most of the CPU cores to full(er) extent. At this point you'd benefit relatively little from 512GB RAM over 256GB, possibly 0-20% overall query time, depending on how well will the DB prefetch data versus how likely is it all to be cached (running 1 query once = everything will need to be loaded from disk anyway).
Your current CPU is anemic by today's standards, so anything even in the mid tier consumer range will be a massive improvement.
Anyway if you want, we could do a quick zoom call (free, no strings attached, not selling anything, just as a gratitude for HIBP), I might be better able to provide my educated guess of what could bottleneck you now and in the future if I know more about approx data/table size, query complexity, etc.