Architecture

One of OwlData's biggest strengths is its adapter-based architecture. Instead of tying your game code to one specific storage API ProfileStore, or DataStore2 OwlData abstracts storage away entirely. Everything covered in Overview (Load, Get, profile:Set...) works identically no matter which backend is actually saving the data underneath.

The two built-in adapters

The framework ships with two adapters out of the box:

1. ProfileStoreAdapter - built on the modern ProfileStore library (by the creator of ProfileService), well suited for robust single-session management, session locking and complex nested data structures.
2. DataStoreAdapter - built on Berezaa's well-known DataStore2 library, known for its cache/history-based save technique that guards against data loss.

You pick one via the Backend field of the Data config table (see Overview):

Owl.Start({
    Data = {
        Backend = "ProfileStore", -- or "DataStore2"
    }
})

Automatic fallback

If the configured primary adapter fails to load for any reason most commonly, the corresponding library is missing from Packages OwlData has an automatic fallback system that gracefully switches to whichever other adapter is actually available without breaking your application code. Your Services keep calling OwlData.Load, profile:Get, profile:Set and so on exactly as before; which adapter is actually doing the work underneath is invisible from that side of the API.

This matters most during a mid-project migration say, moving from DataStore2 to ProfileStore since it means a partially-updated Packages folder degrades gracefully instead of hard-crashing every Service that touches player data.

Where to go next

• Overview - the full OwlProfile API this architecture sits underneath.
• Profiles & Sessions - the async loading lifecycle both adapters implement identically.