We spent some time fixing PDF parsing in PipesHub. Sharing what worked and what didn’t.

Hey folks, I’m one of the founders of PipesHub. For context, PipesHub is an open-source context layer for AI agents. It connects Slack, Drive, Jira, GitHub, Microsoft 365 etc., so people and agents can search company knowledge with citations and permissions respected. You can self-host it and connect your own agents through MCP or SDKs. PipesHub needs to run on anything from a consumer laptop to big servers. PDF parsing was making the laptop part pretty difficult. In our setup, some large PDFs just wouldn’t finish with Docling. Memory usage would get too high, and even when they did finish, parsing took a long time. We tried several fixes, including splitting PDFs into smaller parts, but it was still too heavy for the machines we wanted to support. So we built another PDF parsing path around pdfplumber. Read the text that’s already in the PDF, use rules for layout, and run a layout model on pages that need it. We actually still use Docling’s heron model there. The first version was fast but missed important content. Some financial tables were getting treated as images, which meant their numbers never reached the index. We had to work through that before the speed improvement meant much. Some results after those fixes: Median parsing time: 0.98 → 0.48 seconds/page on a 58-document back-to-back test. P95 peak worker memory: 2.91 → 1.97 GB across 1,228 documents. Pages losing more than half their text: 2.9% → 1.2% . Docling still does better at figure detection, table structure and captions. For our workload, mostly PDFs with an existing text layer, this was a useful trade-off. We wrote up the approach, benchmarks and things that didn’t work: Full write-up Code: github.com/pipeshub-ai/pipeshub-ai Anyone else trying to make PDF ingestion work on smaller machines? Would be interested to hear what’s worked for you.