Parquet storage in Fortifiers

Apache Parquet is a columnar file format used by selected catalog and archive services. It is not the source of truth for every workspace record.

Where the code uses Parquet

The backend includes Parquet-backed product catalogs and selected archives for conversations, memories, audit records, quote history, and document extractions. Coverage depends on the feature and deployed worker configuration. PostgreSQL remains the source of truth for active application records.

Hybrid Query Strategy

Storage and retrieval paths vary by record type. For example, the authenticated conversation API can read active conversations from PostgreSQL and optionally include archived conversations when that archive is available:

1. Active records: The API reads current conversation records from PostgreSQL and checks workspace ownership.
2. Optional archive: When requested, the service checks its Parquet archive and rechecks user and workspace ownership before returning rows.
3. Combine: Results from available sources are merged and returned by the API. Response time depends on the current environment and data size.

This does not mean every agent can search every archive or that all workspace history is retained. Available history depends on the archive type, workspace scope, deployed configuration, and current data.

Storage and retention limits

Parquet stores columns together and can use compression. Actual storage savings and query performance depend on the data and workload; Fortifiers does not publish a fixed compression or latency guarantee here.

• Archive files use the configured storage path for that service. The deployment must protect that path with suitable persistence and access controls.
• Retention, backup, restore, and host-loss protection depend on the deployed storage configuration and written service terms.
• Parquet is not itself a vector database. Qdrant-backed search is available only for features that explicitly integrate with the configured Qdrant service.