Today we're releasing Ditto SDK 5.1, and it is a big one:

• ▪77 platform-level enhancements that benefit every application
• ▪112 SDK-specific refinements across our language SDKs

Ditto SDK 5.0 introduced a new foundation for building edge applications. Ditto SDK 5.1 takes that foundation and makes it faster and stronger.

1. Performance: Faster Queries and Lower Memory Use

Edge applications feel database performance differently from cloud applications. A slow local query doesn't just delay a response from a server. It can block a screen transition, increase battery use, create UI churn, or consume memory on a device with limited resources.

In the 5.1 SDK applications can load data faster, complete writes sooner, and react to changes more quickly, even as their local datasets and workloads grow.

The improvements span nearly every kind of local data operation. In practice, this means more responsive user experiences, less time waiting for data operations, and greater capacity on the same device hardware.

Android retail benchmark

We tested these changes on an Orion O6 Android device using a realistic offline-first retail workload based on the zava DIY dataset. The device held approximately 93,000 documents across stores, categories, products, customers, inventory, orders, and order items.

Across the measured comparison, Ditto 5.1 was faster in 70 of 71 scenarios, with one result too close to call. The geometric-mean improvements by operation were:

Dramatically faster document counts

A count is a query that answers one simple question: how many documents match? Apps use counts all the time, to show how many orders are open, how many items are in stock, or how many results a search found.

Ditto 5.1.0 adds an optimized path for COUNT(*), reducing the benchmark's median execution time significantly.

These improvements make it substantially faster to calculate totals for dashboards, backlog checks, pagination, and application status displays.

Lower memory use

Edge devices like phones, tablets, and point-of-sale terminals have a fixed amount of memory that every app shares. The less memory Ditto uses, the more room your app has for its own work, and the less likely the operating system is to slow it down.

We tested Ditto's memory use improvements by growing a collection from 3,000 to 30,000 documents on an Android device. A document is Ditto's basic unit of data: a JSON-like record, similar to a row in a traditional database. A collection is a group of related documents, similar to a table.

• ▪Total PSS estimates the process's physical RAM footprint (memory). Peak Total PSS is the highest that footprint reached during the test.
• ▪Native heap covers Ditto's Rust core. A heap is the pool of memory a program sets aside while it runs to hold its working data.

These results compare median runtimes from Ditto 5.0.3 and a 5.1.0 preview build. Performance depends on the device, data shape, indexes, and query mix, so test representative workloads on your target hardware.

2. Query Engine: New Ditto Query Capabilities

Performance is only half of the query story in 5.1. DQL is Ditto's query language. In this release it gains the two capabilities customers ask for most: JOIN and composite indexes. A fast query is usually an indexed query, so 5.1 also adds ADVISE to tell you which indexes you're missing.

Join collections directly on the device

A join is a query that combines related data from two collections into one result. It matches records that share a value, like a task and the project it belongs to, so your app gets one combined answer instead of two separate lists.

Applications can now join multiple local collections in a single SELECT statement. Instead of issuing separate queries for tasks and projects and combining them in application code, you express the relationship directly in DQL:

SELECT task._id, task.title, project.name
FROM tasks AS task
JOIN projects AS project ON task.projectId = project._id
WHERE task.status = 'open'

This makes normalized data models practical at the edge. Product catalogs, order histories, task assignments, and multi-tenant views can stay separated into logical collections without forcing every screen to coordinate multiple reads.

Match indexes to real application filters

An index is a lookup structure the database maintains so it can find matching documents without reading the whole collection, much like the index at the back of a book. A composite index covers two or more fields at once, so a query that filters on one field and sorts by another can be answered in a single lookup.

Small Peers now support composite (multi-field) indexes. If an application regularly filters by one field and sorts by another, a single index can represent that complete access pattern:

CREATE INDEX IF NOT EXISTS status_created_idx ON tasks (status, createdAt DESC)

That one index serves the whole query below, both the filter and the ordering:

SELECT * FROM tasks WHERE status = 'open' ORDER BY createdAt DESC

Ditto 5.1 also adds indexes over array and object values.

Find the right indexes with ADVISE

ADVISE turns index optimization into a guided workflow. Prefix any query with ADVISE and Ditto plans how it would execute that query, without actually running it or reading any documents. It inspects the query's filters, sorts, projections, and joins, and spots the places where the engine would have to scan the whole collection. For each one, it responds with the reason an index would help and a ready-to-run CREATE INDEX statement:

ADVISE SELECT * FROM tasks WHERE estimateHours > 8

Ditto identifies the range predicate and recommends an index on estimateHours:

{
  "advice": {
    "statement": "select * from tasks where estimateHours > 8",
    "suggestedIndexes": [
      {
        "collection": "tasks",
        "reason": "range predicates on `estimateHours`",
        "statement": "CREATE INDEX IF NOT EXISTS adv_tasks_estimateHours ON default:`tasks` (`estimateHours` ASC)"
      }
    ]
  }
}

Run the suggested statement yourself, or use ADVISE AND PROVISION to create the recommended indexes automatically. ADVISE can also recommend composite and covering indexes for complex filters, sorting, projections, and joins.

DQL also picks up richer mutation and transformation tools: INSERT ... SELECT creates documents from query results, mutations support RETURNING, deletes can target an explicit list with USE IDS, and new scalar functions and nested WITHIN transformations support more data-processing workflows. RETURNING means a mutation and its confirmation are one operation:

UPDATE tasks
SET status = 'done'
WHERE projectId = 'proj-42' AND status = 'open'
RETURNING _id, status

3. Security: Expanded Certificate Revocation

Security policies at the edge need to keep working when devices are not continuously connected to the cloud.

Here is the scenario that keeps security teams up at night. Imagine a device is lost or stolen, but its certificate is still valid. Previously, peer-to-peer sync would keep working with that device, because its neighbors had no way to know it should no longer be trusted.

In Ditto 5.1, certificate revocation information propagates among Small Peers and from Big Peer to connected Small Peers, and enforcement is enabled by default:

• ▪New connections from a peer presenting a revoked certificate are rejected.
• ▪Matching active connections are terminated the moment a revocation reaches the device.
• ▪Revoked peers cannot simply reconnect through a different neighbor after being disconnected.