Skip to content

MygramDB vs Elasticsearch vs MySQL FULLTEXT

Choosing the right full-text search solution depends on your requirements. Here's a detailed comparison.

Quick Comparison

FeatureMygramDBElasticsearchMySQL FULLTEXT
Latency<1ms50-500ms100-3000ms
DeploymentSingle binaryClusterBuilt-in
Data syncMySQL / MariaDB binlogETL requiredNative
ScalabilitySingle nodeDistributedSingle node
Memory~2.3GB/1M docs (with verify_text)~2-4GB/1M docsBuffer pool
ConcurrencyQPS 11,766HighQPS 2-8
Multibyte / UnicodeN-gram (ICU NFKC)Language pluginsN-gram parser
AnalyticsBasicAdvancedNone
Learning curveLowHighLow

Detailed Comparison

MygramDB

Best for: MySQL-based applications needing fast search without infrastructure complexity.

Pros:

  • Sub-millisecond consistent latency
  • Zero configuration data sync via binlog (MySQL 8.4/9.x and MariaDB 10.6+/11.x)
  • Single binary deployment
  • No cluster management
  • Language-agnostic N-gram tokenization with first-class multibyte UTF-8 support
  • BM25 relevance scoring, highlighting, fuzzy search, faceted aggregation, and synonym expansion (v1.6.0+)

Cons:

  • Single node only (no distributed search)
  • Data must fit in RAM

Elasticsearch

Best for: Large-scale search with advanced analytics requirements.

Pros:

  • Horizontal scalability
  • Advanced features (fuzzy search, highlighting, aggregations)
  • Rich ecosystem and tooling
  • Handles petabytes of data

Cons:

  • Complex cluster management
  • ETL pipeline required
  • Higher operational cost
  • Steeper learning curve
  • JVM tuning required

MySQL FULLTEXT

Best for: Simple search on small datasets (<100K rows).

Pros:

  • No additional infrastructure
  • Native MySQL integration
  • Zero data sync overhead

Cons:

  • Slow (100-3000ms per query)
  • Low throughput under concurrent load (2-8 QPS)
  • Cache-dependent performance
  • Limited scalability

Performance Comparison

See Benchmarks for detailed results on 1.1M Wikipedia articles. Key takeaway: MygramDB delivers 2,634-11,766 QPS with sub-millisecond latency, while MySQL FULLTEXT manages only 2-8 QPS with 300-2,566ms latency.

Migration Path

From MySQL FULLTEXT to MygramDB

  1. Keep MySQL as primary database
  2. Deploy MygramDB alongside
  3. Point search queries to MygramDB
  4. Write operations remain on MySQL
bash
# 1. Start MygramDB
docker run -d -p 11016:11016 \
  -e MYSQL_HOST=your-mysql \
  ghcr.io/libraz/mygram-db:latest

# 2. Search via MygramDB
curl -X POST http://localhost:8080/articles/search \
  -H "Content-Type: application/json" \
  -d '{"q": "search term"}'

From Elasticsearch to MygramDB

Consider migrating if:

  • You don't need distributed search
  • Data fits in single-node RAM
  • Operational complexity is a concern
  • You want simpler MySQL integration

See GitHub for more details.