Deta Space Storage: Choosing Between Base, Drive, and an External Database

The Decision You Face

When building a Deta Space application, the first architectural fork is rarely the HTTP framework or the UI. It is where durable state lives. Deta Space applications are packaged as Micros—stateless HTTP handlers in Python or Node.js. The runtime hands your handler a Base and a Drive handle through environment variables, but it does not give you a writable filesystem or a persistent memory space. Every byte of user data, session state, or uploaded file must be written to a store that survives the invocation.

That constraint narrows the choice to three paths: use the managed Deta Base key-value/document store, use Deta Drive for opaque files, or bypass the managed primitives entirely and talk to an external database over the network. The right answer depends on your access pattern, your tenant model, and how much operational complexity you are willing to accept.

Constraints That Shape the Choice

Before comparing stores, understand the boundaries the platform imposes:

• Stateless execution: Micros are short-lived. You cannot rely on in-memory caches, background threads, or long-lived database connections across requests. Any external database client must be initialized inside the handler or connection-pooled with awareness that the process may be frozen between invocations.
• Per-install data keys: Each user install receives its own data key. This gives you tenant isolation without writing app-level authorization logic, but it also means a single Base instance cannot easily answer cross-user queries, build admin dashboards, or run aggregate analytics.
• Limited query expressiveness: Deta Base supports reads by key or a single-field query with a limit and a last cursor for pagination. There are no joins, transactions, or server-side aggregation. If your mental model is SQL, you will need to redesign your schema.
• Platform lifecycle uncertainty: As of late 2026, Deta has publicly pivoted away from Space toward other products. Continued availability, pricing, and quotas should be treated as unverified. Any new project should include an exit strategy for data export.

Comparing the Options

Option	Best for	Key limitation	Operational cost
Deta Base	Key-centric, tenant-isolated structured data	Single-field queries only; no joins or transactions	Low; managed service
Deta Drive	Opaque blobs, images, user uploads	No query semantics; not for structured data	Low; managed service
External database	Relational queries, joins, reporting, shared cross-user data	Connection handling, secret management, added latency	High; you run or rent the database

Trade-offs in Practice

When Deta Base Fits

Base is the path of least resistance when your access pattern is naturally key-first and tenant-scoped. Because a query filters on only one field, you must encode access patterns into composite keys. For example, if you are building a note-taking app where a user lists their own notes chronologically, a key like owner:timestamp lets you query by the owner prefix and paginate with a cursor. You denormalize aggressively rather than relying on ad-hoc filtering or secondary indexes.

This model works well for personal productivity tools, per-user configuration stores, or any application where the install boundary is also the data boundary. It breaks down the moment you need to answer questions like "show all notes across all users created in the last hour" or join a user table with a permissions table.

When Deta Drive Fits

Drive stores opaque files by name. It is appropriate for profile pictures, PDF exports, or any payload your application treats as a byte stream. It is not a substitute for queryable structured data. If you find yourself wanting to list files by metadata or filter by upload date, you are using the wrong primitive.

When an External Database Wins

If your application requires relational integrity, multi-table joins, transactional writes, or cross-tenant reporting, an external managed database—such as hosted PostgreSQL—restores the query power you lose with Base. The trade-off is operational: you must manage connection strings as secrets, handle connection lifecycle inside a stateless function, and absorb the network round-trip and cold-start latency on every database call.

Because Micros are stateless and short-lived, avoid long-lived connection pools that assume a persistent process. Initialize the client inside the handler, or use a serverless-friendly driver that tolerates frequent reconnects.

Concrete Validation: A Base Round-Trip

Before committing to Base, verify the single-field query behavior and cursor pagination with your real data shape. The following example uses a scratch Space project to confirm that a composite key supports prefix-style listing.

Where to run: inside a Deta Space Micro handler (Python or Node.js runtime), using the Base handle injected through the environment.

Required permissions: the Micro's assigned data key for the target installation.

Meaningful placeholders: OWNER_ID is the per-install user identifier; NOTE_KEY is a composite string such as OWNER_ID:2026-11-11T22:16:44Z.

# Conceptual sketch; confirm exact SDK method names against the current
# Deta Base SDK for your runtime before deploying.
from deta import Deta
import os

deta = Deta(os.environ["DETA_PROJECT_KEY"])
base = deta.Base("notes")

# Put an item with a composite key
base.put({
    "key": "OWNER_ID:2026-11-11T22:16:44Z",
    "title": "Validation note",
    "body": "Confirm single-field query and cursor behavior."
})

# Query by the owner prefix field; adjust field name to match SDK
res = base.query({"owner": "OWNER_ID"}, limit=10)
items = res.items
last = res.last

# Fetch the next page using the cursor
if last:
    next_page = base.query({"owner": "OWNER_ID"}, limit=10, last=last)

Expected checks:

1. The put returns without error and the item is retrievable by its exact key.
2. The query returns only items matching the single field you supplied.
3. The last cursor is present when more results exist and absent when the page is exhausted.
4. Attempting to filter on a second field in the same query fails or is ignored, confirming the single-field constraint.

Relevant risks: SDK method names and query syntax differ between Python and Node.js runtimes and across versions. Do not assume the sketch above is deployable without checking the current SDK documentation.

Validating an External Database Path

If you are leaning toward an external database, do not commit until you have measured the cost inside a Micro.

1. Create a scratch Space project and Micro.
2. Store the database connection string as a secret, not in code.
3. From inside the handler, open a connection, run a representative query, and close it.
4. Measure wall-clock time for the full request, including cold start.
5. Load-test a representative query pattern against Base with your real data shape to confirm single-field filtering and result-size behavior.

If the added latency pushes your handler past acceptable limits, Base may still be the better choice even if the query model is less convenient.

Limitations and Exit Planning

Both managed primitives carry platform risk. Because Deta has pivoted away from Space, treat continued availability, pricing, and quotas as unverified. Per-install data keys also make bulk export non-trivial: you must iterate installations rather than run a single cross-tenant dump.

A practical way to check the result is to run a scheduled export job that walks each install's data key and writes a snapshot to Deta Drive or an external bucket. If that export runs cleanly, you have both a backup and a migration path regardless of the platform's future.