Skip to main content
Mythic Framework uses a dual-database architecture: MongoDB as the primary database for game data, and MySQL for compatibility and relational data. This approach combines the flexibility of NoSQL with the structure of SQL.

Why Two Databases?

MongoDB (Primary)

Best for:
  • Flexible schemas
  • Nested data (inventory, character stats)
  • Fast reads/writes
  • JSON-like documents
  • Scalability

MySQL (Secondary)

Best for:
  • Structured data
  • Complex queries
  • Relationships/joins
  • Compatibility with other resources
  • SQL familiarity

Database Usage

MongoDB Databases

Mythic Framework uses two MongoDB databases:

MySQL Database

MongoDB Usage

Accessing MongoDB

MongoDB operations are handled through the Node.js wrapper in mythic-base using asynchronous callback patterns. Location: mythic-base/core/sv_database.js
Database Architecture: Mythic uses two separate MongoDB databases accessed via the Database component:
  • Database.Game β€” Game data (characters, inventory, vehicles, etc.)
  • Database.Auth β€” Authentication data (users, roles, bans)
After RetrieveComponents(), use Database.Game:method() directly. The full path is Database.Game but the local shorthand is standard.

MongoDB Methods

Find a single document matching query.
Callback receives: (success, document)
Find multiple documents.
Callback receives: (success, documents)
Insert a single document.
Callback receives: (success, insertedDocument)
Update a single document.
Callback receives: (success, updateResult)
Delete a single document.
Callback receives: (success, deleteResult)
Count documents matching query.
Callback receives: (success, count)
Advanced aggregation queries.
Callback receives: (success, results)

MongoDB Query Operators

MySQL Usage

Accessing MySQL

MySQL operations use oxmysql resource:

Common MySQL Queries

Data Models

Character Document (MongoDB)

Inventory Document (MongoDB)

Vehicle Record (MySQL)

Best Practices

Store dynamic, frequently-changing data in MongoDB:
Use MySQL when you need complex relationships:
Add indexes for frequently queried fields:
Always use parameterized queries:
Database operations can fail. Always handle errors in callbacks:
When possible, batch database operations:
Cache frequently accessed, rarely changing data:

Performance Optimization

MongoDB Optimization

MySQL Optimization

Database Migration

When updating schemas:

Next Steps

Database Setup

Initial database configuration

Database API

Database API reference

Architecture

Framework architecture overview

Configuration

Database connection settings
When in doubt, use MongoDB for game data. It’s more flexible and handles nested/changing data better. Use MySQL when you specifically need relational queries or compatibility with other resources.