adrai

Author here. Happy to answer questions about the technical decisions, the data, or the v26.0.0 release.

The team at Convex is building an awesome product. You're right that you can absolutely achieve real-time functionality with Convex, but we think about the problem with a different philosophy and focus.

The way we see it, it comes down to the level of abstraction and what problem you're trying to solve:

Convex is a powerful, full-featured backend platform. It gives you a database, serverless functions (mutations and queries), and file storage. It's a fantastic choice if you're looking to build your entire backend on a modern, reactive stack. You write your logic in server-side functions, and Convex provides the infrastructure.

Vaultrice aims to be a simpler, more focused real-time component that often requires no backend code from you at all. Our goal is to feel like a frontend tool—like a "cloud-based localStorage".

The key difference is in the developer experience:

With Vaultrice, for things like cross-domain state sharing or a simple "who's online" list, you just instantiate our SDK on the client with your credentials and start using it. There are no backend functions to write. Our SyncObject API, where you just modify a JavaScript object and it syncs, is designed to completely abstract away the server.

So, a good way to think about it might be:

Choose Convex when: You need a complete backend replacement, with server-side logic, schema validation, and complex queries.

Choose Vaultrice when: You already have a backend (or don't want one for this feature) and you just need to drop in a real-time, cross-domain state layer with a dead-simple, frontend-friendly API.

Don't know exactly what you mean by users... users in the Game... probably yes. users in Vaultrice... no, in Vaultrice that would be 1 object (per game) of 1 class

Hey, thanks for the great questions!

Offline-first: That's a key distinction. The Vaultrice SDK is currently designed for "online-first" and "offline-sometimes" use cases. Its main strength is real-time, consistent synchronization that relies on an active connection.

Proper offline-first support with automatic conflict resolution is on our roadmap, as we have a backlog item for it ;-) However, you can easily achieve a robust offline capability in your own code today by using localStorage as a fallback.

Here’s a simple wrapper pattern (not tested, just for illustration) that reads from Vaultrice when online and falls back to a local cache when offline:

import { NonLocalStorage } from '@vaultrice/sdk';

// --- A simple offline-first wrapper --- function createOfflineStore(credentials, id) { const vaultriceStore = new NonLocalStorage(credentials, id); const localCacheKey = `vaultrice_cache_${id}`;

  // Helper to get local data
  const getLocal = () => JSON.parse(localStorage.getItem(localCacheKey) || '{}');

  return {
    // SET: Write to both Vaultrice (if online) and localStorage
    async setItem(key, value) {
      // Always update the local cache immediately
      const localData = getLocal();
      localData[key] = value;
      localStorage.setItem(localCacheKey, JSON.stringify(localData));

      try {
        // Attempt to write to the cloud
        await vaultriceStore.setItem(key, value);
      } catch (error) {
        console.warn('Offline: Data saved locally.', error.message);
      }
    },

    // GET: Try Vaultrice first, fallback to localStorage
    async getItem(key) {
      try {
        const item = await vaultriceStore.getItem(key);
        if (item) {
            // Optional: Update local cache with fresh data
            const localData = getLocal();
            localData[key] = item.value;
            localStorage.setItem(localCacheKey, JSON.stringify(localData));
            return item.value;
        }
      } catch (error) {
        console.warn('Offline: Reading from local cache.', error.message);
      }
      // Fallback to local cache
      return getLocal()[key];
    }
  };

}

Production Readiness: Yes, for its intended use case, Vaultrice is ready for production. We've put a lot of focus on a layered security model (from API key restrictions to E2EE) and built it on top of Cloudflare's infrastructure, which gives us a reliable and scalable foundation.

Hope that helps clarify things! Appreciate you checking it out.

and as long as it's used on those and other apps, it will for sure continue to exist ;-)