Nexus V1.X DataStoreManager System - Development Showcase

NikiSorix · May 3, 2025, 7:24am

(Still in Development - Preview Features)

Hello developers! Today, I want to introduce Nexus , an advanced DataStore management system currently in development. This system is designed to optimize data handling in Roblox games, improving performance, reliability, and ease of use.

Key Features

Single DataStore Structure

Nexus simplifies data management by storing multiple datasets inside a single DataStore. Instead of creating multiple DataStores for different purposes (like ProfileData, Leaderstats, Inventory, etc.), you can structure everything in one organized table.

Example:

local PlayerData = Nexus.InitNexus("MainDataStore", player.UserId, {
    Coins = 0,
    Inventory = {},
    Stats = {
        Kills = 0,
        Deaths = 0
    }
})

Instead of:

local ProfileData = DataStoreService:GetDataStore("ProfileData"):GetAsync(player.UserId)
local Leaderstats = DataStoreService:GetDataStore("Leaderstats"):GetAsync(player.UserId)
local Inventory = DataStoreService:GetDataStore("Inventory"):GetAsync(player.UserId)

This reduces DataStore calls , minimizes throttling risks , and keeps data well-structured .

Blocking Multiple DataStores for the Same Player

Nexus prevents accidental duplicate DataStores for the same player. If you try to create another InitNexus for the same UserId, it will block the attempt and return the existing data.

Example:

local MainData = Nexus.InitNexus("MainDataStore", player.UserId, {}) -- ✅ Works  
local Leaderstats = Nexus.InitNexus("LeaderstatsDataStore", player.UserId, {}) -- ❌ Blocked

This ensures data consistency and avoids unnecessary API calls.

V2.X Coming Soon

local MainData = Nexus.InitNexus("MainDataStore", player.UserId, {}) -- ✅ Works  
local Leaderstats = Nexus.InitNexus("LeaderstatsDataStore", player.UserId, {}) -- ✅ Works

We are working to implement multiple keys, without risk of blocking or data loss.

Smart Request Management

Priority-Based Queue (Higher-priority requests execute first)
Automatic Retries (If a request fails, it retries with delays)
Memory & Local Backup Cache (Reduces load times if DataStore fails)
Adaptive Throttling (Adjusts request rates based on success/failures)

Automatic Deep Proxies for Nested Tables

Nexus automatically tracks changes in nested tables, so you don’t need to manually save each modification.

PlayerData.Coins += 100 -- Auto-detects changes  
PlayerData.Inventory["Sword"] = true -- Also tracked

Current Limitations (Work in Progress)

Still in testing phase (needs more real-game validation)
Requires optimization for very large datasets
Backup system needs more testing

Who Should Use Nexus?

Developers who hate managing multiple DataStores
Games with complex player data (RPGs, simulators, Tycoons)
Experienced devs who want better throttling protection
New devs who want a simpler, error-proof DataStore system

Final Thoughts

Nexus aims to simplify DataStore management, reduce throttling, and keep data structured efficiently. If you’re interested in testing it or have suggestions, let me know!

Would you like a detailed tutorial when it’s fully released?

FAQ: Nexus DataStore System

“Does Nexus require using a single key for large datasets?”

Current Implementation:

Yes, Nexus v1.x is designed to use a single key per player by default. This approach offers several benefits:

Simplicity: No need to manually manage multiple keys
Consistency: All player data remains centralized
Performance: Fewer calls to the DataStore API

Current limits:

Each key supports up to 4MB of compressed data (~3.2MB uncompressed)
Auto-compression reduces size by 30-70% using an efficient algorithm

But we’re actively working on an even better solution!

We’re developing a new version that will:

Automatically manage multiple keys when needed
Maintain the same ease of use – you’ll still interact with a single object
Ensure robustness – no data loss or confusing error messages
Optimize performance – intelligently distributing data

In the meantime, for edge cases that exceed current limits, we recommend:

Manually splitting very large datasets
Using MemoryStore for temporary data
Grouping non-critical information

Our commitment: Bring Nexus’ simplicity to any scale scenario without sacrificing reliability or performance. The new version is in advanced development!

Want to be a beta tester or have specific use cases? Let me know!

I will work extensively to make Nexus complete and well structured to accommodate any scale of game. But in the meantime, let me know what you think about the DataStore, and what I can add/improve or remove, I’m open to receiving feedback.