Full-text indexing on encrypted SQL Server FileTables — a capability
that native TDE can’t deliver and Always Encrypted breaks entirely.
Keep PDFs, Word docs, scans, and attachments encrypted at rest while
CONTAINS
and FREETEXT
queries keep working.
SQL Server’s own encryption models leave a gap for document stores — and third-party tools that fill it typically break full-text search. We closed both.
FileTables store documents (PDFs, Word, scans) in the file system while exposing them as a queryable table. Full-text indexing reads the raw file bytes through iFilters. But:
Encryptionizer sits between the SQL Server engine and the file system. During full-text index population, iFilters receive the content they need to extract searchable terms. The underlying files remain encrypted at rest, in backups, and on removable media.
CONTAINS and FREETEXT queries work without modification.Application writes a PDF, .docx, or scanned image to the FileTable as usual — via SQL INSERT, Windows file share, or API.
Encryptionizer intercepts the write. AES-256 ciphertext is what actually lands on disk. Backups of the FileStream container inherit the encryption automatically.
When SQL Server’s full-text index crawl runs, it calls the appropriate iFilter for each file type. Encryptionizer provides in-memory access so the iFilter can extract terms — the file on disk stays encrypted.
Your app runs CONTAINS(file_stream, 'HIPAA') — or any other T-SQL full-text predicate — and gets matching documents back. No second index, no external search service, no schema changes.
-- Standard SQL Server full-text query. Works unchanged against encrypted FileTables. SELECT name, file_stream.GetFileNamespacePath() AS path FROM dbo.PatientDocuments WHERE CONTAINS(file_stream, '"informed consent" NEAR rhinoplasty') AND creation_time > DATEADD(day, -90, GETDATE()); -- Under the hood: files are AES-256 encrypted on disk. The query returns plaintext hits. -- No application change. No second search index. No schema rewrite.
Any organization that must simultaneously encrypt, retain, and search documents — without sending them to a cloud search service.
Attorneys need to search across thousands of encrypted case documents — contracts, depositions, exhibits, email archives — during active litigation or compliance review.
Scanned intake forms, signed consents, imaging reports, and referral letters — PHI that must be encrypted under HIPAA while remaining searchable for clinicians and billing.
CUI, ITAR, and CMMC-regulated document stores that can’t move to commercial cloud search services. Must stay in controlled, encrypted, on-prem SQL Server environments.
Document-management, claims-processing, and case-management platforms that embed SQL Server and ship to regulated customers. Embed Encryptionizer via OEM license and make encrypted-search a selling point.
Every approach trades something. This one doesn’t ask you to choose between compliance, search, or simplicity.
| Capability | Encryptionizer | Native TDE | Always Encrypted | Azure Cognitive Search |
|---|---|---|---|---|
| Files encrypted at rest on disk | ✓ | Partial (FileStream gaps) | ✓ | Depends on storage |
| Full-text search works on encrypted content | ✓ | ✓ | ✕ | ✓ |
| Runs on SQL Server Express | ✓ | ✕ | Partial | ✓ |
| Keeps data on-premise (no cloud required) | ✓ | ✓ | ✓ | ✕ |
| No second index or service to secure | ✓ | ✓ | ✓ | ✕ |
| Works with CMMC / ITAR / CUI workloads | ✓ | Edition-dependent | ✓ | GovCloud only |
| No application code changes required | ✓ | ✓ | ✕ | ✕ |
| FIPS 140-2 validated cryptography | ✓ | ✓ | ✓ | Tier-dependent |
Comparison reflects publicly documented behavior as of 2026. Individual deployments vary — we’ll validate against your specific environment during the free evaluation.
What file types can be indexed?
Anything a SQL Server iFilter supports: PDF (with Adobe or Foxit iFilter), Microsoft Office (.docx, .xlsx, .pptx), plain text, HTML, XML, and OCR’d image formats. Installing a third-party iFilter for scanned medical images or CAD files works the same way.
What’s the performance overhead?
For AES-256 file decryption on modern multi-core servers, the typical overhead during index population is in the low single-digit percent range, and query-time overhead is often unmeasurable because the index itself is unchanged. We’ll benchmark on your hardware during the free evaluation.
What happens to the full-text index itself — is it encrypted too?
The full-text catalog lives inside the database file, which Encryptionizer encrypts as part of the standard database-level TDE. So the index, the FileTable metadata, the backups, and the underlying document bytes are all encrypted at rest.
Can I point my existing DMS or EHR at this without changes?
Yes. Encryptionizer is transparent to applications. If your software already uses FileTables and full-text search against SQL Server, it will continue to work exactly as it does today — with encrypted files on disk instead of plaintext.
Is there an OEM / ISV embedding license?
Yes. If you’re shipping a product that embeds SQL Server and you’d like your customers to get encrypted-document-search by default, we license Encryptionizer on a distribution-volume basis. Contact sales for a quote tailored to your deployment model.