Nexus Core v1.7.0: Moving from MongoDB-Centric to Multi-Database Architecture
Today I released Nexus Core v1.7.0, and this is one of the most important architectural changes since the project's first stable release.
Nexus Core was originally designed around MongoDB as its persistence layer.
That worked well while the project was smaller, but it also created a strong coupling between the core architecture and a single database engine.
With v1.7.0, that changes.
Nexus Core now has a database provider/driver abstraction that allows addons to work with different database engines without being tightly coupled to MongoDB.
What changed?
The persistence layer is now built around a generic database provider interface.
MongoDB is still supported and remains the default adapter, but Nexus Core now ships with:
- MongoDB
- PostgreSQL
- MySQL
The important part is that database selection is no longer hard-coded into the addon implementation.
Instead, addons can target a configured database provider.
Multiple databases in a single Nexus Core instance
One of the main goals of this release was to support multiple database sources at the same time.
For example, you can have:
Nexus Core
│
├── PlayerDataAddon
│ └── PostgreSQL
│
├── EconomyAddon
│ └── MySQL
│
└── StatisticsAddon
└── MongoDB
Different addons can target different databases while running inside the same Nexus Core instance.
Connection routing is resolved dynamically based on the addon context and active configuration.
This makes the architecture significantly more flexible for applications that don't want to force every workload into the same database engine.
Configuration changes
The configuration schema now supports multiple named data sources.
Conceptually, the configuration can define sources such as:
dataSources:
default:
driver: mongodb
uri: mongodb://localhost:27017/nexus
postgres:
driver: postgresql
uri: jdbc:postgresql://localhost:5432/game
mysql:
driver: mysql
uri: jdbc:mysql://localhost:3306/economy
The existing single-MongoDB configuration remains compatible by treating it as the default data source.
Why abstraction instead of database-specific implementations?
The main motivation wasn't simply to add PostgreSQL and MySQL.
I wanted to change the architectural boundary.
Previously, persistence logic could naturally evolve around MongoDB-specific concepts.
That makes every future database integration more expensive because the core system has to understand the implementation details of each database.
The new approach is:
Nexus Core
│
Database Provider
│
┌─────────────┼─────────────┐
│ │ │
MongoDB PostgreSQL MySQL
Adapter Adapter Adapter
The core works against the abstraction while each adapter handles database-specific behavior.
This should make adding future database engines significantly easier.
Integration testing
Adding multiple database implementations also introduces a new problem:
How do we know that every adapter actually behaves correctly?
For v1.7.0, integration test suites were added for the supported database adapters.
The tests cover areas such as:
- Connection lifecycle
- CRUD operations
- Nexus Core protocol compatibility
- Database adapter behavior
This is important because an abstraction is only useful if its implementations provide consistent behavior where the framework expects it.
Breaking changes
v1.7.0 does contain a breaking change.
DataAddon#getDatabase() and DataAddon#getCollection() semantics now depend on the selected database driver.
Addons that simply use the default MongoDB data source should remain largely unaffected.
However, addons that directly use MongoDB-specific APIs need to migrate to the new provider interface if they want to support non-MongoDB databases.
This is an intentional trade-off.
The goal was to remove the architectural limitation rather than keep compatibility with every MongoDB-specific implementation detail forever.
Why this matters for the future
The biggest change in v1.7.0 isn't PostgreSQL.
It is the fact that the database is no longer the architecture.
Nexus Core can now treat the database as an implementation detail behind a provider layer.
That opens the door for future adapters and makes the persistence layer much easier to evolve independently from the rest of the system.
The broader architecture is becoming:
Application / Addons
│
▼
Nexus Core
│
┌──────┼────────┐
▼ ▼ ▼
Cache Messaging Persistence
│
▼
Database Provider
│
┌─────────┼─────────┐
▼ ▼ ▼
MongoDB PostgreSQL MySQL
This is the direction I want Nexus Core to continue moving toward: a modular infrastructure layer where individual components can evolve without forcing the entire system to depend on one implementation.
What's next?
With the database abstraction in place, adding additional database adapters becomes much more practical.
The focus can now move from:
"How do we make Nexus Core work with MongoDB?"
to:
"How do we make Nexus Core work with any suitable persistence backend?"
That's a much better architectural foundation for the project.
Links
Documentation:
https://nexus-core.mintlify.site/
Github:
https://github.com/mustafabinguldev/nexus-cache-orchestrator
If you're working on database abstraction, plugin architectures, or backend infrastructure, I'd be interested in hearing how you approach this problem.
Feedback and architectural criticism are very welcome.
Top comments (0)