A managed data store, wired straight into your workflows. No external database. No extra connector.

Tables live in younifyd's own storage — nothing else to provision

Define a table's fields with real types — string, integer, float, boolean, array, JSON, enum, object, or a nested array of objects — and it's ready to read and write from immediately. There's no external database to stand up, no connection string to store, no separate Connection to authenticate.

Records are keyed by a primary key, single or composite, stored directly as the record's own identifier — so a lookup by primary key is a native point read, not an indexed query layered on top of the storage engine.

9 field typesincluding recursive nested objects and arrays

Filtering is fast because it's restricted to fields you've actually indexed

Any field can be flagged searchable to get a live secondary index — up to five per table. Filter a Find call on a searchable field and it's fast at any scale; filter on a field that isn't indexed and the call is rejected outright, rather than silently falling back to a full collection scan that gets slower every month as the table grows.

Listing results never uses offset-based pagination, which degrades badly on large tables. Every list is cursor-paginated instead, so page 5,000 of a multi-million-row table costs the same as page one.

5 indexed fieldsper table, enforced at query time — no silent slow scans

Insert, Get, Find, Update, Upsert, Delete, Bulk Upsert — as native steps

A data table shows up as a connector inside the workflow builder itself. Reading or writing to it is a drag-and-drop step next to every other integration in your workflow, not a separate API you call out to and parse the response from.

Bulk Upsert is built for real import volume: writes are chunked into batches of 500 and sent as a single unordered bulk operation, so one malformed row in a 10,000-row import doesn't block the other 9,999 — it's reported and skipped, not fatal.

500-row chunksper Bulk Upsert batch — one bad row won't block the rest

A record change can kick off a workflow automatically

Subscribe a workflow to a table's create, update, or delete events and it fires the moment a matching change happens — queued for delivery with automatic retry (three attempts, exponential backoff) so a transient failure downstream doesn't lose the event.

That turns a table into a reactive trigger source, not just passive storage. Write a row to a "pending_orders" table from anywhere and a fulfilment workflow can pick it up automatically — no polling, no separate scheduler to wire up.

create · update · deleteany of the three can trigger a workflow

Primary-key reads don't need a secondary index at all

Because the primary key — single or composite — is stored as the record's own identifier rather than as a regular indexed field, a Get by primary key is the fastest read path the storage engine offers: a direct point lookup, not a query plan.

That distinction matters once a table holds millions of rows: the lookups your workflow does most often — "get this customer," "get this order" — stay fast regardless of table size, while search-style filtering uses the separate, capped set of indexed fields.

point-lookupspeed for any Get by primary key, single or composite