The process list was red. Disk I/O was spiking. Lnav was open, but the sheer volume of data felt like trying to drink from a fire hose. You could see the bottleneck—not in the tool, but in the way it was being run. That’s when it became clear: scalability isn’t about handling logs. It’s about handling this much log, this fast, without blinking.
Understanding Lnav Scalability
Lnav processes log files locally. This makes it fast for small to medium datasets, but once you throw tens of gigabytes of logs at it, you start seeing limits. Performance depends on CPU speed, available RAM, and disk throughput. The indexing process that makes search so quick can also be the choke point at scale. For a single machine, Lnav can handle a lot. But when logs grow faster than your ability to read them, that's when its scalability challenge becomes obvious.
When Local Hits the Ceiling
If you’re tailing real-time logs that stream endlessly, Lnav can handle it—until your server becomes the limiting factor. Once logs exceed system memory, search slows. Pattern matching still works, but filtering giant log sets stops being instant. You start waiting. Waiting at 3 a.m. is expensive.