Document Engine Selection

Relevant source files

This document describes RAGFlow's pluggable document storage architecture, which supports three backend engines for storing document chunks and their vector embeddings: Elasticsearch, Infinity, and OpenSearch. It covers how to select an engine via configuration, the architecture that enables this flexibility, and the process for switching between engines.

For information about the broader storage architecture including MySQL, MinIO, and Redis, see Data Storage Architecture. For object storage configuration (MinIO/S3/OSS/Azure), see Configuration Management.

Overview of Document Engines

RAGFlow uses a document store to persist parsed document chunks along with their full-text indexes and vector embeddings. The system supports three pluggable backend engines that can be selected via a single environment variable without code changes.

Supported Engines

Engine	Version	Default	Primary Strengths	Limitations
Elasticsearch	8.11.3	✓ Yes	Mature full-text search, proven at scale, extensive tooling	Higher memory usage (~8GB), complex configuration
Infinity	0.7.0	✗ No	Native vector storage, SQL interface, lower memory footprint	Newer project, no official ARM64 support
OpenSearch	2.19.1	✗ No	AWS compatibility, Apache 2.0 license, Elasticsearch-compatible API	Similar memory requirements to ES

All three engines implement the DocStoreConnection interface defined in common/doc_store/doc_store_base.py38-187 ensuring API compatibility. The application code remains unchanged regardless of which engine is selected.

Architecture diagram: Pluggable Document Engine

Sources: docker/.env13-20 README.md273-291 docker/README.md1-19 common/doc_store/doc_store_base.py38-187

Configuration System

Environment Variable Selection

The document engine is selected via the DOC_ENGINE variable in docker/.env:

Valid values:

elasticsearch (default)
infinity
opensearch
oceanbase (experimental)
seekdb (experimental)

This variable controls two aspects:

Which Docker Compose profile is activated (determines which container starts)
Which connection class is instantiated by the application

Sources: docker/.env13-20 README.md273-291

Docker Compose Profile Mapping

The COMPOSE_PROFILES variable in docker/.env28 is constructed as:

This ensures only the selected engine's container is started when running docker compose up.

Sources: docker/.env28 docker/docker-compose.yml

Engine-Specific Configuration Variables

Each engine has its own set of configuration variables in docker/.env:

Elasticsearch:

Infinity:

OpenSearch:

These variables are interpolated into service_conf.yaml.template when containers start, creating the runtime configuration.

Sources: docker/.env30-52 docker/README.md23-46 docs/configurations.md44-70

Architecture and Implementation

DocStoreConnection Interface

All document engines implement the DocStoreConnection abstract base class defined in common/doc_store/doc_store_base.py38-187:

The base class defines the contract that all engines must fulfill:

Method	Purpose	Return Type
`search()`	Hybrid search combining text and vector	`(DataFrame, int)`
`get()`	Retrieve single document by ID	`dict \| None`
`insert()`	Bulk insert documents	`list[str]`
`update()`	Update documents matching condition	`bool`
`delete()`	Delete documents matching condition	`bool`
`create_idx()`	Initialize index/table with schema	`bool`
`delete_idx()`	Drop index/table	`bool`

Sources: common/doc_store/doc_store_base.py38-187

Match Expression System

All engines support a unified query expression language defined by common/doc_store/doc_store_base.py21-35:

Each engine translates these abstract expressions into engine-specific query syntax. For example, a MatchTextExpr becomes:

Elasticsearch: query_string query rag/utils/es_conn.py95-98
Infinity: match_text() builder method rag/utils/infinity_conn.py241-250
OpenSearch: query_string query rag/utils/opensearch_conn.py

Sources: common/doc_store/doc_store_base.py21-35 rag/utils/es_conn.py92-98 rag/utils/infinity_conn.py241-250

Connection Instantiation

The application instantiates the correct connection class based on settings.DOC_ENGINE:

All three connection classes use the @singleton decorator common/decorator.py to ensure only one instance exists per process.

Sources: rag/utils/es_conn.py33 rag/utils/infinity_conn.py29 rag/utils/opensearch_conn.py40

Engine-Specific Details

Elasticsearch Configuration

Connection parameters (rag/utils/es_conn.py common/doc_store/es_conn_base.py27-66):

Key characteristics:

Uses Elasticsearch 8.11.3 by default docker/.env31
Requires vm.max_map_count >= 262144 README.md158-178
Implements full-text search via query_string rag/utils/es_conn.py95-98
Vector search via knn field type rag/utils/es_conn.py106-112
Memory limit configurable via MEM_LIMIT docker/.env65

Index mapping: Elasticsearch uses dynamic mappings defined at index creation time common/doc_store/es_conn_base.py68-133 Key fields include:

docnm_kwd: Keyword field for document names
content_ltks: Text field for full-text content
q_*_vec: Dense vector fields for embeddings (size determined at runtime)

Sources: docker/.env30-42 rag/utils/es_conn.py33-173 common/doc_store/es_conn_base.py27-133

Infinity Configuration

Connection parameters (rag/utils/infinity_conn.py29-30 common/doc_store/infinity_conn_base.py35-84):

Key characteristics:

Native vector database optimized for RAG rag/utils/infinity_conn.py30-440
Connection pooling via InfinityConnectionPool common/doc_store/infinity_conn_pool.py15-119
Three protocol options: Thrift (default), HTTP, PostgreSQL
Table per knowledge base: {index_name}_{kb_id} pattern rag/utils/infinity_conn.py233-239
Schema defined in conf/infinity_mapping.json1-41

Field mapping: Infinity uses a different field naming scheme than Elasticsearch:

ES Field	Infinity Field	Type	Analyzer
`docnm_kwd`	`docnm`	`varchar`	`rag-coarse`, `rag-fine`
`title_tks`	`docnm`	`varchar`	`rag-coarse`, `rag-fine`
`important_kwd`	`important_keywords`	`varchar`	`rag-coarse`, `rag-fine`
`content_with_weight`	`content`	`varchar`	`rag-coarse`, `rag-fine`

The conversion logic is in rag/utils/infinity_conn.py44-86 and rag/utils/infinity_conn.py362-389

Table creation: When a table doesn't exist, Infinity automatically creates it with the appropriate schema rag/utils/infinity_conn.py326-347 The schema includes:

Base fields from conf/infinity_mapping.json
Optional table-specific fields based on parser type
Embedding columns sized according to the first document

Sources: docker/.env67-73 rag/utils/infinity_conn.py29-440 common/doc_store/infinity_conn_base.py35-427 conf/infinity_mapping.json1-41

OpenSearch Configuration

Connection parameters (rag/utils/opensearch_conn.py41-97):

Key characteristics:

Fork of Elasticsearch with AWS integration rag/utils/opensearch_conn.py41-770
Similar API to Elasticsearch but with differences in vector search
Uses knn queries for vector similarity rag/utils/opensearch_conn.py
Compatible with Elasticsearch mappings with minor adjustments

Sources: docker/.env44-52 rag/utils/opensearch_conn.py41-770

Switching Between Engines

Prerequisites for Switching

Before switching engines, ensure:

The target engine's container is configured in docker-compose.yml
System requirements are met (e.g., vm.max_map_count for ES/Infinity)
You have backups if preserving data is critical

Warning: Switching engines requires clearing existing data volumes. The down -v command deletes all document chunks and vectors README.md283

Sources: README.md273-294

Switch Procedure

Step-by-step process:

Stop all containers and clear volumes:
The -v flag is critical—it removes Docker volumes containing existing data README.md283
Update the engine selection in docker/.env20:
Restart containers:
Docker Compose reads the updated COMPOSE_PROFILES and starts only the infinity container.
Verify the switch:

Sources: README.md273-294 README_zh.md273-293 docs/configurations.md1-42

Data Migration Strategies

Critical warning: The docker compose down -v command used during engine switching permanently deletes all document chunks and vector embeddings. Only MySQL metadata (dataset configurations, user data) is preserved README.md283

Impact of switching engines:

Data Type	Preserved	Lost	Recovery Method
User accounts	✓ Yes (MySQL)	-	N/A
Dataset configurations	✓ Yes (MySQL)	-	N/A
Document metadata	✓ Yes (MySQL)	-	N/A
Parsed chunks	✗ No (ES/Infinity/OS)	All chunks	Re-parse documents
Vector embeddings	✗ No (ES/Infinity/OS)	All vectors	Re-parse documents
Original files	✓ Yes (MinIO/S3)	-	N/A

Migration workflow for production systems:

Step-by-step migration procedure:

Pre-migration backup:
Document current state:
- List all datasets and their embedding models
- Note chunk methods used per dataset
- Record total document count and parsing status
Perform engine switch (see Switching Between Engines)
Post-migration recovery:
Re-parse documents:
- Navigate to each dataset in the UI
- Trigger re-parsing for all files
- Monitor parsing progress in task executor logs
- Important: Use the same embedding model as before to maintain consistency

Downtime estimation:

Switch operation: 5-10 minutes
Re-parsing: Varies by dataset size (roughly 1-5 minutes per 100 pages)

Alternative: Test before migration (recommended for production):

Field name compatibility issues:

Infinity uses different field names than Elasticsearch rag/utils/infinity_conn.py362-389 The application handles conversion automatically, but manual exports/imports are not supported:

Elasticsearch Field	Infinity Field	Notes
`docnm_kwd`	`docnm`	Automatic conversion
`important_kwd`	`important_keywords`	Array handling differs
`content_with_weight`	`content`	Weight calculation differs

Sources: README.md283 docker/.env13-20 rag/utils/infinity_conn.py362-389

Platform-Specific Limitations

ARM64 platforms:

Infinity does not officially support Linux/ARM64 README.md294
Elasticsearch and OpenSearch work on ARM64 but require custom Docker images README.md188-189
See Build System and CI/CD for building ARM64-compatible images

Sources: README.md188-189 README.md294

Architecture Integration

Service Layer Access

The document store connection is accessed throughout the service layer:

Services never directly instantiate engine-specific classes. Instead, they import from a common module that returns the appropriate singleton based on configuration.

Sources: rag/utils/es_conn.py33 rag/utils/infinity_conn.py29

Index/Table Naming Conventions

Each engine uses slightly different naming patterns:

Elasticsearch/OpenSearch:

Document chunks: {index_name} (e.g., ragflow_chunk)
Metadata: ragflow_doc_meta_{tenant_id}
Single index per type

Infinity:

Document chunks: {index_name}_{kb_id} (e.g., ragflow_chunk_abc123)
Metadata: ragflow_doc_meta_{tenant_id}
Separate table per knowledge base for isolation rag/utils/infinity_conn.py233-239

This difference is transparent to the application layer due to the abstraction interface.

Sources: rag/utils/infinity_conn.py229-292 rag/utils/es_conn.py175-211

Performance and Trade-offs

Detailed Comparison Matrix

Aspect	Elasticsearch	Infinity	OpenSearch
Maturity	Very mature (10+ years)	Newer project (~2 years)	Mature (ES fork, 3+ years)
Vector Search Performance	Good (knn plugin)	Excellent (native HNSW)	Good (knn plugin)
Full-Text Search Quality	Excellent (BM25)	Good (custom analyzers)	Excellent (BM25)
Memory Usage	High (~8GB min)	Moderate (~4-6GB)	High (~8GB min)
Disk I/O	Moderate	Lower (optimized storage)	Moderate
Scalability	Excellent (sharding/clustering)	Good (single-node optimized)	Excellent (sharding/clustering)
Query Language	JSON DSL	SQL + Builder API	JSON DSL
Multi-Tenancy	Index per tenant	Table per KB	Index per tenant
Monitoring Tools	Kibana, extensive ecosystem	Limited	OpenSearch Dashboards
ARM64 Support	Unofficial (custom build)	Not supported	Unofficial (custom build)
Production Adoption	Very high	Growing	High (especially AWS)

Sources: docker/.env65 README.md294 docker/.env30-73

Resource Requirements

Minimum system requirements (from README.md147-151):

CPU:  4+ cores (x86_64 recommended)
RAM:  16+ GB (system total)
Disk: 50+ GB SSD (for index storage)

Per-container memory limits docker/.env65:

Storage growth estimates:

Elasticsearch/OpenSearch: ~1.5-2x raw document size (with vectors and full-text indexes)
Infinity: ~1.2-1.5x raw document size (optimized vector storage)
Vector dimensions significantly impact storage (768-dim vectors ~3KB per chunk)

Sources: README.md147-151 docker/.env65

Selection Decision Tree

Use Case Recommendations

Choose Elasticsearch if:

Production deployment requiring proven stability and extensive monitoring
Distributed/clustered deployment across multiple nodes
Existing Elasticsearch infrastructure or expertise in your organization
Need for advanced full-text search features (synonyms, language analyzers)
Integration with Kibana for visualization and debugging

Choose Infinity if:

Vector search performance is the top priority
Preference for SQL-like query interface over JSON DSL
Single-node or small-scale deployment
Lower memory footprint is important
Dataset has high vector-to-text ratio
Caution: Not suitable for ARM64 platforms README.md294

Choose OpenSearch if:

Deploying on AWS infrastructure (especially with managed OpenSearch service)
Need Elasticsearch-compatible API without licensing concerns
Require open-source governance model
Existing AWS ecosystem integration

Sources: README.md294 docker/.env13-20 Analysis based on implementation characteristics

File	Purpose	Key Settings
docker/.env13-73	Engine selection and connection parameters	`DOC_ENGINE`, `ES_PORT`, `INFINITY_HOST`
docker/service_conf.yaml.template	Runtime service configuration (auto-generated)	Interpolated from .env
conf/infinity_mapping.json1-41	Infinity table schema definition	Field types and analyzers
docker/docker-compose.yml	Container orchestration	Service profiles and dependencies
docker/docker-compose-base.yml	Dependency-only compose file	ES, Infinity, MySQL, Redis, MinIO

Sources: docker/.env docker/README.md1-165 docs/configurations.md1-207

Document Engine Selection

Relevant source files

Overview of Document Engines

Supported Engines

Engine	Version	Default	Primary Strengths	Limitations
Elasticsearch	8.11.3	✓ Yes	Mature full-text search, proven at scale, extensive tooling	Higher memory usage (~8GB), complex configuration
Infinity	0.7.0	✗ No	Native vector storage, SQL interface, lower memory footprint	Newer project, no official ARM64 support
OpenSearch	2.19.1	✗ No	AWS compatibility, Apache 2.0 license, Elasticsearch-compatible API	Similar memory requirements to ES

Architecture diagram: Pluggable Document Engine

Sources: docker/.env13-20 README.md273-291 docker/README.md1-19 common/doc_store/doc_store_base.py38-187

Configuration System

Environment Variable Selection

The document engine is selected via the DOC_ENGINE variable in docker/.env:

Valid values:

elasticsearch (default)
infinity
opensearch
oceanbase (experimental)
seekdb (experimental)

This variable controls two aspects:

Which Docker Compose profile is activated (determines which container starts)
Which connection class is instantiated by the application

Sources: docker/.env13-20 README.md273-291

Docker Compose Profile Mapping

The COMPOSE_PROFILES variable in docker/.env28 is constructed as:

This ensures only the selected engine's container is started when running docker compose up.

Sources: docker/.env28 docker/docker-compose.yml

Engine-Specific Configuration Variables

Each engine has its own set of configuration variables in docker/.env:

Elasticsearch:

Infinity:

OpenSearch:

These variables are interpolated into service_conf.yaml.template when containers start, creating the runtime configuration.

Sources: docker/.env30-52 docker/README.md23-46 docs/configurations.md44-70

Architecture and Implementation

DocStoreConnection Interface

All document engines implement the DocStoreConnection abstract base class defined in common/doc_store/doc_store_base.py38-187:

The base class defines the contract that all engines must fulfill:

Method	Purpose	Return Type
`search()`	Hybrid search combining text and vector	`(DataFrame, int)`
`get()`	Retrieve single document by ID	`dict \| None`
`insert()`	Bulk insert documents	`list[str]`
`update()`	Update documents matching condition	`bool`
`delete()`	Delete documents matching condition	`bool`
`create_idx()`	Initialize index/table with schema	`bool`
`delete_idx()`	Drop index/table	`bool`

Sources: common/doc_store/doc_store_base.py38-187

Match Expression System

All engines support a unified query expression language defined by common/doc_store/doc_store_base.py21-35:

Each engine translates these abstract expressions into engine-specific query syntax. For example, a MatchTextExpr becomes:

Elasticsearch: query_string query rag/utils/es_conn.py95-98
Infinity: match_text() builder method rag/utils/infinity_conn.py241-250
OpenSearch: query_string query rag/utils/opensearch_conn.py

Sources: common/doc_store/doc_store_base.py21-35 rag/utils/es_conn.py92-98 rag/utils/infinity_conn.py241-250

Connection Instantiation

The application instantiates the correct connection class based on settings.DOC_ENGINE:

All three connection classes use the @singleton decorator common/decorator.py to ensure only one instance exists per process.

Sources: rag/utils/es_conn.py33 rag/utils/infinity_conn.py29 rag/utils/opensearch_conn.py40

Engine-Specific Details

Elasticsearch Configuration

Connection parameters (rag/utils/es_conn.py common/doc_store/es_conn_base.py27-66):

Key characteristics:

Uses Elasticsearch 8.11.3 by default docker/.env31
Requires vm.max_map_count >= 262144 README.md158-178
Implements full-text search via query_string rag/utils/es_conn.py95-98
Vector search via knn field type rag/utils/es_conn.py106-112
Memory limit configurable via MEM_LIMIT docker/.env65

Index mapping: Elasticsearch uses dynamic mappings defined at index creation time common/doc_store/es_conn_base.py68-133 Key fields include:

docnm_kwd: Keyword field for document names
content_ltks: Text field for full-text content
q_*_vec: Dense vector fields for embeddings (size determined at runtime)

Sources: docker/.env30-42 rag/utils/es_conn.py33-173 common/doc_store/es_conn_base.py27-133

Infinity Configuration

Connection parameters (rag/utils/infinity_conn.py29-30 common/doc_store/infinity_conn_base.py35-84):

Key characteristics:

Native vector database optimized for RAG rag/utils/infinity_conn.py30-440
Connection pooling via InfinityConnectionPool common/doc_store/infinity_conn_pool.py15-119
Three protocol options: Thrift (default), HTTP, PostgreSQL
Table per knowledge base: {index_name}_{kb_id} pattern rag/utils/infinity_conn.py233-239
Schema defined in conf/infinity_mapping.json1-41

Field mapping: Infinity uses a different field naming scheme than Elasticsearch:

ES Field	Infinity Field	Type	Analyzer
`docnm_kwd`	`docnm`	`varchar`	`rag-coarse`, `rag-fine`
`title_tks`	`docnm`	`varchar`	`rag-coarse`, `rag-fine`
`important_kwd`	`important_keywords`	`varchar`	`rag-coarse`, `rag-fine`
`content_with_weight`	`content`	`varchar`	`rag-coarse`, `rag-fine`

The conversion logic is in rag/utils/infinity_conn.py44-86 and rag/utils/infinity_conn.py362-389

Table creation: When a table doesn't exist, Infinity automatically creates it with the appropriate schema rag/utils/infinity_conn.py326-347 The schema includes:

Base fields from conf/infinity_mapping.json
Optional table-specific fields based on parser type
Embedding columns sized according to the first document

Sources: docker/.env67-73 rag/utils/infinity_conn.py29-440 common/doc_store/infinity_conn_base.py35-427 conf/infinity_mapping.json1-41

OpenSearch Configuration

Connection parameters (rag/utils/opensearch_conn.py41-97):

Key characteristics:

Fork of Elasticsearch with AWS integration rag/utils/opensearch_conn.py41-770
Similar API to Elasticsearch but with differences in vector search
Uses knn queries for vector similarity rag/utils/opensearch_conn.py
Compatible with Elasticsearch mappings with minor adjustments

Sources: docker/.env44-52 rag/utils/opensearch_conn.py41-770

Switching Between Engines

Prerequisites for Switching

Before switching engines, ensure:

The target engine's container is configured in docker-compose.yml
System requirements are met (e.g., vm.max_map_count for ES/Infinity)
You have backups if preserving data is critical

Warning: Switching engines requires clearing existing data volumes. The down -v command deletes all document chunks and vectors README.md283

Sources: README.md273-294

Switch Procedure

Step-by-step process:

Stop all containers and clear volumes:
The -v flag is critical—it removes Docker volumes containing existing data README.md283
Update the engine selection in docker/.env20:
Restart containers:
Docker Compose reads the updated COMPOSE_PROFILES and starts only the infinity container.
Verify the switch:

Sources: README.md273-294 README_zh.md273-293 docs/configurations.md1-42

Data Migration Strategies

Impact of switching engines:

Data Type	Preserved	Lost	Recovery Method
User accounts	✓ Yes (MySQL)	-	N/A
Dataset configurations	✓ Yes (MySQL)	-	N/A
Document metadata	✓ Yes (MySQL)	-	N/A
Parsed chunks	✗ No (ES/Infinity/OS)	All chunks	Re-parse documents
Vector embeddings	✗ No (ES/Infinity/OS)	All vectors	Re-parse documents
Original files	✓ Yes (MinIO/S3)	-	N/A

Migration workflow for production systems:

Step-by-step migration procedure:

Pre-migration backup:
Document current state:
- List all datasets and their embedding models
- Note chunk methods used per dataset
- Record total document count and parsing status
Perform engine switch (see Switching Between Engines)
Post-migration recovery:
Re-parse documents:
- Navigate to each dataset in the UI
- Trigger re-parsing for all files
- Monitor parsing progress in task executor logs
- Important: Use the same embedding model as before to maintain consistency

Downtime estimation:

Switch operation: 5-10 minutes
Re-parsing: Varies by dataset size (roughly 1-5 minutes per 100 pages)

Alternative: Test before migration (recommended for production):

Field name compatibility issues:

Infinity uses different field names than Elasticsearch rag/utils/infinity_conn.py362-389 The application handles conversion automatically, but manual exports/imports are not supported:

Elasticsearch Field	Infinity Field	Notes
`docnm_kwd`	`docnm`	Automatic conversion
`important_kwd`	`important_keywords`	Array handling differs
`content_with_weight`	`content`	Weight calculation differs

Sources: README.md283 docker/.env13-20 rag/utils/infinity_conn.py362-389

Platform-Specific Limitations

ARM64 platforms:

Infinity does not officially support Linux/ARM64 README.md294
Elasticsearch and OpenSearch work on ARM64 but require custom Docker images README.md188-189
See Build System and CI/CD for building ARM64-compatible images

Sources: README.md188-189 README.md294

Architecture Integration

Service Layer Access

The document store connection is accessed throughout the service layer:

Services never directly instantiate engine-specific classes. Instead, they import from a common module that returns the appropriate singleton based on configuration.

Sources: rag/utils/es_conn.py33 rag/utils/infinity_conn.py29

Index/Table Naming Conventions

Each engine uses slightly different naming patterns:

Elasticsearch/OpenSearch:

Document chunks: {index_name} (e.g., ragflow_chunk)
Metadata: ragflow_doc_meta_{tenant_id}
Single index per type

Infinity:

Document chunks: {index_name}_{kb_id} (e.g., ragflow_chunk_abc123)
Metadata: ragflow_doc_meta_{tenant_id}
Separate table per knowledge base for isolation rag/utils/infinity_conn.py233-239

This difference is transparent to the application layer due to the abstraction interface.

Sources: rag/utils/infinity_conn.py229-292 rag/utils/es_conn.py175-211

Performance and Trade-offs

Detailed Comparison Matrix

Aspect	Elasticsearch	Infinity	OpenSearch
Maturity	Very mature (10+ years)	Newer project (~2 years)	Mature (ES fork, 3+ years)
Vector Search Performance	Good (knn plugin)	Excellent (native HNSW)	Good (knn plugin)
Full-Text Search Quality	Excellent (BM25)	Good (custom analyzers)	Excellent (BM25)
Memory Usage	High (~8GB min)	Moderate (~4-6GB)	High (~8GB min)
Disk I/O	Moderate	Lower (optimized storage)	Moderate
Scalability	Excellent (sharding/clustering)	Good (single-node optimized)	Excellent (sharding/clustering)
Query Language	JSON DSL	SQL + Builder API	JSON DSL
Multi-Tenancy	Index per tenant	Table per KB	Index per tenant
Monitoring Tools	Kibana, extensive ecosystem	Limited	OpenSearch Dashboards
ARM64 Support	Unofficial (custom build)	Not supported	Unofficial (custom build)
Production Adoption	Very high	Growing	High (especially AWS)

Sources: docker/.env65 README.md294 docker/.env30-73

Resource Requirements

Minimum system requirements (from README.md147-151):

CPU:  4+ cores (x86_64 recommended)
RAM:  16+ GB (system total)
Disk: 50+ GB SSD (for index storage)

Per-container memory limits docker/.env65:

Storage growth estimates:

Elasticsearch/OpenSearch: ~1.5-2x raw document size (with vectors and full-text indexes)
Infinity: ~1.2-1.5x raw document size (optimized vector storage)
Vector dimensions significantly impact storage (768-dim vectors ~3KB per chunk)

Sources: README.md147-151 docker/.env65

Selection Decision Tree

Use Case Recommendations

Choose Elasticsearch if:

Production deployment requiring proven stability and extensive monitoring
Distributed/clustered deployment across multiple nodes
Existing Elasticsearch infrastructure or expertise in your organization
Need for advanced full-text search features (synonyms, language analyzers)
Integration with Kibana for visualization and debugging

Choose Infinity if:

Vector search performance is the top priority
Preference for SQL-like query interface over JSON DSL
Single-node or small-scale deployment
Lower memory footprint is important
Dataset has high vector-to-text ratio
Caution: Not suitable for ARM64 platforms README.md294

Choose OpenSearch if:

Deploying on AWS infrastructure (especially with managed OpenSearch service)
Need Elasticsearch-compatible API without licensing concerns
Require open-source governance model
Existing AWS ecosystem integration

Sources: README.md294 docker/.env13-20 Analysis based on implementation characteristics

File	Purpose	Key Settings
docker/.env13-73	Engine selection and connection parameters	`DOC_ENGINE`, `ES_PORT`, `INFINITY_HOST`
docker/service_conf.yaml.template	Runtime service configuration (auto-generated)	Interpolated from .env
conf/infinity_mapping.json1-41	Infinity table schema definition	Field types and analyzers
docker/docker-compose.yml	Container orchestration	Service profiles and dependencies
docker/docker-compose-base.yml	Dependency-only compose file	ES, Infinity, MySQL, Redis, MinIO

Sources: docker/.env docker/README.md1-165 docs/configurations.md1-207

Document Engine Selection

Overview of Document Engines

Supported Engines

Configuration System

Environment Variable Selection

Docker Compose Profile Mapping

Engine-Specific Configuration Variables

Architecture and Implementation

DocStoreConnection Interface

Match Expression System

Connection Instantiation

Engine-Specific Details

Elasticsearch Configuration

Infinity Configuration

OpenSearch Configuration

Switching Between Engines

Prerequisites for Switching

Switch Procedure

Data Migration Strategies

Platform-Specific Limitations

Architecture Integration

Service Layer Access

Index/Table Naming Conventions

Performance and Trade-offs

Detailed Comparison Matrix

Resource Requirements

Selection Decision Tree

Use Case Recommendations

Related Configuration Files

On this page

Document Engine Selection

Overview of Document Engines

Supported Engines

Configuration System

Environment Variable Selection

Docker Compose Profile Mapping

Engine-Specific Configuration Variables

Architecture and Implementation

DocStoreConnection Interface

Match Expression System

Connection Instantiation

Engine-Specific Details

Elasticsearch Configuration

Infinity Configuration

OpenSearch Configuration

Switching Between Engines

Prerequisites for Switching

Switch Procedure

Data Migration Strategies

Platform-Specific Limitations

Architecture Integration

Service Layer Access

Index/Table Naming Conventions

Performance and Trade-offs

Detailed Comparison Matrix

Resource Requirements

Selection Decision Tree

Use Case Recommendations

Related Configuration Files

On this page