A Firebase alternative for app data: simpler persistence for prototypes

If you searched for Firebase alternative for app data, you want the shortest reliable path from working code to a public URL — without standing up servers, learning a sprawling cloud dashboard, or entering a credit card before you have a single user. This guide walks through exactly how to do that with jsdeck, what the trade-offs are, and when a different tool is genuinely the better call. We will keep it practical: real steps, real commands, and honest caveats.

What jsdeck's datastore actually is

It is a per-app JSON key-value store. Every record has a string key, an arbitrary JSON value, three optional string index columns (idx1–idx3) for filtering, and an updatedAt timestamp. You read and write it over a small REST API straight from your static frontend, or through the @jsdeck/toolkit npm client. There is no server for you to run, patch, or scale.

Why this matters for Firebase alternative for app data

Most prototypes do not need Postgres. They need to save a settings object, persist a high score, store a list of submissions, or remember what a user did last time. A JSON store hits that sweet spot: you keep your data shaped exactly like your app state, with none of the schema, migration, or connection-pool ceremony of a full database.

Modes and access control

The datastore runs in one of two modes. In public_read, anyone can read records but writes require your store_ key. In private, both reads and writes require the key. PUT requests are rate-limited per IP. The key is a shared secret suitable for non-sensitive app data — never put real secrets in client-side code.

Example: save and load JSON

// Save
await fetch('https://jsdeck.com/api/v1/public/data/YOUR-SLUG/records/settings', {
  method: 'PUT',
  headers: {
    'Authorization': 'Bearer store_YOUR_KEY',
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({ value: { theme: 'dark', lang: 'en' } }),
});

// Load
const res = await fetch('https://jsdeck.com/api/v1/public/data/YOUR-SLUG/records/settings');
const { value } = await res.json();

Per-user data with owner rows

Need each visitor to have their own private data? Combine the datastore with visitor auth. After a visitor logs in you receive a session token; write a record with visibility: "owner" and that row becomes readable and writable only by that user. The store_ key alone cannot read it. That is what makes gated demos and simple per-user apps possible without a full backend.

When it does not fit

Be honest with yourself about the data model. The datastore is not the right tool for relational data with joins, schema migrations, or transactions; it offers no realtime subscriptions, no server-side functions or triggers, no full-text search, and no file/blob storage. Its query model is "key plus up to three string indexes (AND-combined)", not arbitrary SQL. If you need those, reach for Postgres/Supabase or a full backend.

Who this is for, and when not to use jsdeck

Good fit: static frontends, single-page apps, demos, portfolios, MVPs, AI-generated exports, and apps that need a little JSON persistence or lightweight visitor login.

Not a fit: apps that require a long-running Node server, server-side rendering at request time, WebSocket backends, private server-side secrets, background jobs, or a full relational database. For those, a platform like the alternatives discussed across our comparisons hub will serve you better — and that is a feature of choosing deliberately, not a compromise.

Frequently asked questions

Is Firebase alternative for app data really free?

Yes. jsdeck offers free static hosting with HTTPS for projects like this, with no credit card required to start. Optional features such as the datastore and visitor auth are available when you need them.

Do I need a server to use the datastore?

No. The datastore is a hosted REST API you call directly from your static frontend. There is nothing for you to run, scale, or patch.

How do I keep each user's data private?

Use visitor auth and write records with visibility: "owner". Those rows are only accessible with the owner's token, not the shared datastore key.

Next steps

• Explore more guides in the datastore hub
• Follow the getting started guide to deploy your first app
• Read the developer docs for datastore, secure accounts (auth API), and CLI deploy details