dbzero-pro

dbzero-pro is the advanced edition of dbzero for applications that require stronger performance, tighter access control, and more operational flexibility than the standard open-source edition.

It is designed for production systems where data volume, concurrency, authorization complexity, and latency requirements grow beyond the needs of a single-process or low-throughput application. dbzero-pro extends the core object model with optimized storage layouts, advanced tagging and query primitives, context-aware security controls, and asyncio-compatible execution features.

The features below are organized by the type of capability they add to dbzero.

Pro capabilities

Security and access control

Protected fields

Protected fields add field-level access checks to memo objects declared with @db0.memo(protect_fields=True). When data masking is activated during db0.init(), dbzero checks reads, creates, updates, and deletes at normal Python object access points.

Use protected fields for records where different accounts or execution contexts may see or modify different fields, such as customer data, tenant-scoped records, financial fields, and other sensitive application data.

Denied reads raise PermissionError by default, or return the configured missing-value placeholder when data masking is configured to mask unavailable values.

Learn more in Security and memo.

Data filtering predicates

Data filtering predicates add row-level security for memo objects declared with @db0.memo(access_control=True). When data filtering is activated during db0.init(), dbzero applies the current db0.predicate(...) at query, fetch, deserialized-query, and application-visible reference access boundaries.

Use data filtering for multi-tenancy, per-account grants, role-based visibility, tenant isolation, and high-granularity authorization rules. Predicates can use the same tag and query grammar as find(), including composite tags and negative predicates.

Learn more in Security, predicate, and memo.

Data modeling and storage efficiency

Immutable memo objects

Immutable memo objects are created with @db0.memo(immutable=True) for data that is written once and then expected to remain unchanged, such as audit traces, events, append-only logs, and historical records.

They use an optimized immutable layout with embedded storage for suitable nested data. This improves performance and storage utilization, with storage savings that may reach 10-20x for complex immutable data graphs.

Immutable memo objects retain the regular memo capabilities: tagging, typed queries, references, drop by reference, UUIDs, and fetch(). They are also useful where security matters because the data model helps prevent accidental or unauthorized tampering after creation.

Learn more in Classes and the @memo decorator, memo, tags, and uuid.

Interned memo objects

Interned memo objects are content-addressed immutable memo objects declared with @db0.memo(immutable=True, intern=True). Equal temporary Python instances of the same memo class resolve to one canonical durable dbzero identity when materialized, UUID-ed, referenced, tagged, or otherwise given durable identity. The same UUID is guaranteed, which avoids duplicate durable objects for labels, addresses, permission masks, event fragments, and other repeated immutable values.

Use db0.materialized(...) to force canonical lookup immediately when you need a standalone reference or UUID. Leave an interned value unmaterialized when passing it into another immutable object if you want dbzero to materialize lazily and embed it in the parent layout instead of first creating a referenced standalone object.

Interned objects retain normal memo behavior, but they do not replace reference and tag lifetime management. Duplicate durable identities are not created while a canonical value is live, and interned values are dropped when normal references and tags no longer keep them alive.

Learn more in Classes and the @memo decorator, memo, uuid, and fetch.

Tagging and query operations

Composite tags

Composite tags let you model structured relationships as ordered tags with two or more elements, such as access grants, tenant-scoped categories, or workflow assignment.

For example, db0.as_tag("GRANT-READ", workspace, user) can tag documents readable by one user in one workspace, while db0.as_tag("CATEGORY", tenant, "invoice", "overdue") can tag tenant-scoped overdue invoices.

Learn more in Working with Tags, as_tag, and find.

Passive tags

Passive tags are searchable tags that do not keep the tagged object alive. They are useful for high-churn labels such as permissions, access predicates, temporary audit markers, and generated classifications.

Add them with db0.tags(obj, passive=True).add(...), remove them with normal remove(), and query them with a positive non-passive predicate such as a memo type or regular tag.

Learn more in Working with Tags, tags, and find.

Set-based tagging

Set-based tagging applies tag additions or removals to every object matched by a live find() query. It is the optimized dbzero-pro form of batch tagging for query results, avoiding Python-level loops for large result sets.

For example, db0.tags(db0.find(Invoice, "active", "overdue")).add("needs-review") marks all matching invoices in one operation, while db0.tags(db0.find("temporary")).remove("temporary") clears a tag from the whole matched set.

Learn more in Working with Tags, tags, and find.

Execution controls

Async atomic operations

The regular db0.atomic() context manager is available in the open-source edition for synchronous Python code. dbzero-pro adds db0.async_atomic() for asyncio tasks that need the same rollback-safe atomic updates without blocking the event loop.

Use async with db0.async_atomic(): in async request handlers, workers, and background jobs. Concurrent async atomic blocks are serialized cooperatively, and regular db0.atomic() raises inside asyncio tasks to avoid event-loop deadlocks.

Learn more in Atomic updates, atomic, and async_atomic.

Read-only execution contexts

db0.read_only() protects blocks that are known and expected to be non-mutating. Reads, queries, and fetches continue to work, but accidental dbzero writes fail immediately.

Use it around validation, authorization checks, reports, query handlers, and dry-run style logic. db0.in_read_only() lets integration layers detect the protected context before dispatching mutating calls.

There is no separate async_read_only() API. Use with db0.read_only(): in both synchronous and async functions.

Learn more in Data consistency and transactions, read_only, and in_read_only.

Availability

The current public API documentation describes the Standard / Open Source edition unless a page is explicitly marked otherwise.