Using Deta Base as a NoSQL Store for a Detaspace Micro

The practical answer

If you need persistent storage for a Detaspace micro without operating a database, use Deta Base, Detaspace's managed NoSQL store. A micro written in Python or another supported language can write JSON documents with base.put() and read them by unique key with base.get(). The useful constraint is that Base is key-based: plan your access pattern around item keys, not relational queries.

How Deta Base works in a micro

Deta Base stores items, which are JSON documents. Every item must include a unique key field. The official Deta SDK serializes the document and sends HTTPS requests to Deta's control plane, the backend service that manages storage. A Detaspace micro is a serverless function or app deployed to Deta Space, so the SDK runs inside that micro and needs network access to the control plane.

Worked configuration: Python micro with Deta Base

This example assumes you have the Deta CLI installed, a Deta account, and the official Python SDK added to your project. Exact package and CLI command names can change, so confirm them in the current SDK README before copying commands.

Create main.py:

from deta import Deta

# Provide the project key through the SDK configuration or an
# environment variable. Do not hard-code it in the repository.
deta = Deta('<project-key>')
base = deta.Base('visitors')

def record_visit(key='default'):
    item = base.get(key)
    if item is None:
        item = {'key': key, 'count': 1}
    else:
        item['count'] = item.get('count', 0) + 1
    return base.put(item)

def read_count(key='default'):
    item = base.get(key)
    return item.get('count', 0) if item else 0

Run from your local terminal:

1. Install the SDK: pip install deta (package name may vary by SDK version).
2. Initialize the project: deta init or deta space init, depending on your CLI version.
3. Deploy the micro: deta deploy or deta space deploy. Confirm the current command in the Deta CLI documentation.
4. Invoke record_visit(), then read_count() with the same key.

Permissions: a Deta account with permission to create bases and deploy micros in the target space.

Placeholders: replace <project-key> with your project key, and visitors with your intended base name.

Expected check: after deployment, the Deta console or CLI output should show the base and at least one item. Reading the item by key should return a document containing count.

Risk: if the project key is committed to source control, rotate it immediately. Writes can fail if you exceed per-item size or tier quotas.

Limits and common mistakes

Limit or behavior	Practical implication
Per-item size cap	Confirm the current maximum item size in the SDK docs; do not store large documents or files in Base.
Fetch pagination	base.fetch() returns a page of results, not necessarily every item. Use the returned cursor to fetch additional pages.
Free-tier quotas	Request and storage allowances vary by plan and region. Check usage in the Deta console after a test deployment.
No joins or cross-item transactions	Model data so a single key lookup returns what you need. Do not assume atomic updates across multiple items.
No secondary indexes	Queries are key-based unless the current SDK documents an index feature.
No binaries	Store blobs in Deta Drive, not Deta Base.

Common mistakes include treating Base like a relational database, storing images or PDFs in items, embedding secrets in source code, and assuming fetch() returns the full collection in one call.

Verify the result

1. Deploy a minimal micro that calls put and then get with the same key.
2. Confirm the returned document matches what was written.
3. Open the Deta console or review CLI output to verify base usage, request counts, and remaining tier quota.
4. Review the official SDK README and changelog to confirm that put, get, and fetch are current for your SDK version.

Review before production

Deta's public cloud and Space offerings have changed over time. Treat the SDK method names, CLI commands, and quota values in this guide as unconfirmed until you verify them against the current official documentation. There is no native rollback for a put; test writes against a dedicated base or a test key prefix before writing to production data.