Good news — yes, the full CFR going back to its 1938 inception is available online, and the answer to whether OCR is needed depends on which source you're using.
What's available and where
The Library of Congress maintains a digitized historical collection of the CFR from 1938 to 1995. From 1996 to the present, GovInfo (from GPO) provides editions in digitally certified PDF format, appearing as they do in print. And for the current regulatory text, the eCFR is a joint project of the Office of the Federal Register and GPO, updated daily as an unofficial HTML edition. LOC + 2
For commercial sources, HeinOnline has the most comprehensive historical CFR archive, covering 1938 to the present, browsable by year, title, indexes, and List of Sections Affected. Lexis begins with 1981 and Westlaw with 1984. Jenkins Law LibraryJenkins Law Library
Do you need OCR?
It depends on what you're trying to do. The LoC collection and GovInfo PDFs are already digitized — you can view and search them. But the older LoC volumes (especially pre-1970s) are essentially scanned page images. If you want to extract the text programmatically — say, to build a searchable database or pipe regulatory text into a pipeline like the one you're building — then yes, you'd likely need to run OCR on the older scanned volumes, since many are image-based PDFs without an embedded text layer (or with a low-quality one).
The GovInfo PDFs from 1996 onward are born-digital and have proper text layers, so no OCR needed there. The eCFR is structured HTML, which is the easiest to work with programmatically.
Two-column OCR tools
The CFR's two-column layout is a classic pain point — naive OCR will interleave lines from the left and right columns, producing garbled output. Several tools handle this well:

Tesseract (open source, the workhorse) — with its --psm 1 (automatic page segmentation) or --psm 3 mode, it does decent column detection. For CFR-style layouts, you'd often pair it with a layout analysis preprocessor.
OCR4all — an open-source system that explicitly supports two-column layouts through its layout segmentation step, where you can define separate text blocks for each column and configure whitespace column separators. Ocr4all
Chandra 2 — a newer open-source 4B-parameter model that preserves layout structure, maintaining two-column layouts, sidebars, and header hierarchies in its output, and runs on a single consumer GPU. Themenonlab
LlamaParse — uses vision-language models for "agentic OCR" with layout-aware processing that understands multi-column reading order. LlamaIndex
ABBYY FineReader — commercial, but widely regarded as the gold standard for complex layouts. It handles two-column legal/regulatory documents reliably out of the box.
Adobe Acrobat Pro — can do OCR with column detection, though users have reported issues with two-column text being intermixed, requiring manual zone definition. adobe

Practical recommendation for your use case
Given you're already building an FCC legal research pipeline with SQLite and eyeCite, the most pragmatic approach for historical CFR text would probably be to start with HeinOnline's archive (if you have access through your FCC library resources — most federal agencies do) since their PDFs tend to have better text layers than the raw LoC scans. For anything that still needs OCR, Tesseract with a layout segmentation preprocessor like docTR or LayoutParser would give you a solid open-source pipeline, and you could spot-check with Chandra 2 for the trickier volumes.