Skip to content

Data and Storage

LibreChat's persistent application data is stored in Railway. The Local AI Server performs inference and does not hold the LibreChat conversation database, uploaded-file bucket, Meilisearch index, or Railway vector database.

Storage inventory

Observed usage is a point-in-time Railway measurement from 2026-07-21.

Data Service and location Persistence Observed usage Allocated capacity
Users, conversations, Agents, permissions, file metadata MongoDB, Railway US East mongodb-volume mounted at /data/db 1,328 MB 50,000 MB
Search index Meilisearch, Railway US East meilisearch-volume mounted at /meili_data 797 MB 50,000 MB
RAG vectors, chunks, and Bauer structured database PostgreSQL/pgvector, Railway US East vectordb-volume mounted at /var/lib/postgresql/data 915 MB 50,000 MB
Uploaded file objects Railway S3-compatible bucket, Amsterdam librechat-files 417 objects / 5.1 MB Railway bucket allocation
Model weights Local AI Server Fedora server storage under /srv/localai/models Not part of Railway Host storage
Generated import manifests and resume state Operator workstation Repository-ignored tmp/ workspace Temporary/recreatable Workstation storage

The volume figures include database and index overhead, not only user document content.

Database responsibilities

MongoDB

MongoDB is LibreChat's primary application database. It stores accounts, sessions, conversations, messages, Agent definitions, group and permission records, and file associations.

Deleting MongoDB data would remove the application-level relationships that define which files and tools belong to each Agent, even if raw objects remained in S3.

Meilisearch

Meilisearch supports fast search across LibreChat records. It is a derived index but still has a persistent volume to avoid rebuilding after every restart.

PostgreSQL and pgvector

The VectorDB service has two responsibilities:

  • LibreChat RAG storage for document chunks and 1,024-dimensional embeddings.
  • A dedicated bauer_twin database and login for synthetic project, part, document, relationship, full-text, trigram, vector, and terminology-alias data.

The bauer_twin.terminology_aliases table contains 74 version-controlled aliases. It maps recognized user vocabulary to canonical engineering values without adding projects or changing compatibility data. The table is synchronized by an additive startup migration and does not rebuild document or project embeddings.

The same VectorDB service now also contains the additive bauer_rag_v2 schema for private Bauer RAG V2 evaluation. Its active bauer-rag-v2-2026-07 index contains derived metadata, lexical search vectors, table-aware chunks, embeddings, entities, and index-run state for the same 373 source file IDs. It does not duplicate S3 objects or replace V1 rows. The active namespace belongs only to the private V2 test Agent.

The Bauer database is logically isolated inside the same PostgreSQL service and physical volume. It is not hosted on the Local AI Server.

For a normal question, MongoDB is consulted for the authorized file IDs and PostgreSQL/pgvector is searched for matching chunks. MongoDB is not used as a second semantic search engine, and the original S3 objects are not parsed again. See File Search and RAG Request Flow.

Object storage

The librechat-files bucket stores uploaded source objects through LibreChat's s3 file strategy. MongoDB holds metadata and Agent associations; PostgreSQL holds searchable chunks and vectors.

File ingestion path

flowchart LR
    Source["Source PDF, HTML, or Markdown"] --> Prep["Deduplication, text extraction, OCR"]
    Prep --> Upload["LibreChat upload"]
    Upload --> S3["Railway S3 object"]
    Upload --> Mongo["MongoDB metadata and Agent association"]
    Upload --> RAG["RAG API"]
    RAG --> Embed["Local embedding model"]
    Embed --> PG["Railway pgvector chunks"]

The Bauer preparation process uses SHA-256 deduplication and OCR for image-only PDFs. The current import reduced 550 PDF/HTML inputs to 373 exact unique searchable sources; 35 PDFs required OCR.

This path runs for new or changed uploads. An ordinary question embeds only the query and searches the existing pgvector rows; it does not repeat the ingestion path.

Backup and recovery

The deployment currently has persistent volumes but no repository-controlled, tested cross-service backup-and-restore procedure. A complete recovery point must keep these components consistent:

  1. MongoDB application records.
  2. PostgreSQL/pgvector data, including bauer_twin.
  3. Meilisearch indexes or a documented rebuild path.
  4. S3 file objects.
  5. The Git-pinned LibreChat configuration and provisioning state.

Recovery planning must now also retain the bauer_rag_v2 schema and active index-run metadata. Normal V1 rollback does not require dropping that schema.

A production-ready backup design should define Railway snapshots or logical exports, S3 replication/export, encryption, retention, restore order, and a scheduled restore drill. Volume persistence protects against container replacement; it is not a complete backup strategy.

Capacity triggers

Alerting should be added before any persistent volume reaches 70% usage. The present volumes are below 3% of their 50 GB allocations, but document growth affects MongoDB, Meilisearch, PostgreSQL, and object storage at different rates.

Open Questions

  • Which Railway backup plan and retention period will apply to production?
  • Must customer knowledge bases use separate buckets, encryption keys, database services, or Railway projects?
  • Should Railway data remain in the present US East region for European customer demonstrations?

Sources

  • Railway volume and bucket status captured on 2026-07-21
  • D:\02_Code\LibreChat_Setup\README.md
  • D:\02_Code\LibreChat_Setup\scripts\prepare-bauer-corpus.py
  • D:\02_Code\LibreChat_Setup\services\bauer-twin-api\bauer_twin\schema.sql
  • D:\02_Code\LibreChat_Setup\services\bauer-twin-api\bauer_twin\terminology_schema.sql