7 ms·
There's no high performance database that wont take all of your memory (at least for size of data) if you let it. That's because it's much, MUCH faster to do i
by hilariously 6mo ago
There's no high performance database that wont take all of your memory (at least for size of data) if you let it.
That's because it's much, MUCH faster to do it that way, though if you can deal with certain type of latency trade offs for throughput something like turbopuffer can do wonders for your costs.
- giancarlostoro 6mo agoMySQL doesnt eat up all 8GB of my system when I need to query a table with indexed values, MongoDB seems to eat it all up.
- vscode-rest 6mo agoYou paid one hundred bucks for that eight gb of ram, do you really want it to just sit there unused?
- giancarlostoro 6mo agoNo, but my manager was wondering why our website was slowing to a crawl.
- vscode-rest 6mo agoIs the DB on the same host as the web server?
- hilariously 6mo agoIt is more likely they did not leave enough overhead for the host operating system, which is a classic issue.
- giancarlostoro 6mo agoI don't really remember, to be fair this was nearly 10 years ago now. Upon some googling now, I do see a way to limit just how much Mongo sucks up for data + index. I am curious if it would have been a smoother experience, if this configuration was even available then.
- fleroviumna 5mo ago[dead]
- hilariously 6mo agoIf the data is < ram size and if you read that data again and its off disk again its the slowest it can possibly be, there's a reason most databases implement a buffer cache (actually making writes insanely faster as well) but yeah, MySQL is generally not a very good operational database with all the ones I have tinkered with.