@rebasepro/types 0.11.1-canary.gfd39654 → 0.12.0

package/src/controllers/data.ts

@@ -116,12 +116,12 @@ export interface FindResponse<M extends Record<string, unknown> = Record<string,
 
 
 /**
- * Fluent query builder for the **admin CMS** — resolves to `FindResponse<M>`
+ * Fluent query builder for the **admin admin** — resolves to `FindResponse<M>`
  * (Snapshot-wrapped rows).
  *
  * @internal App developers should use {@link SDKQueryBuilderInterface}
  * (flat rows, returned by `client.data.*` / `context.data.*`). This
- * Snapshot-flavored variant backs the admin CMS internals only.
+ * Snapshot-flavored variant backs the admin admin internals only.
  *
  * @group Data
  */
@@ -138,13 +138,13 @@ export interface QueryBuilderInterface<M extends Record<string, unknown> = Recor
 }
 
 /**
- * A single collection's CRUD accessor for the **admin CMS** — every method
+ * A single collection's CRUD accessor for the **admin admin** — every method
  * resolves to `Snapshot`-wrapped rows (`FindResponse<M>` / `Snapshot<M>`).
  *
  * @internal App developers do **not** use this. The public, symmetric surface
  * is {@link SDKCollectionClient} (flat rows), exposed as `client.data.products`
  * in the SDK and `context.data.products` in framework callbacks. This
- * Snapshot-flavored accessor backs the admin CMS view-model only.
+ * Snapshot-flavored accessor backs the admin admin view-model only.
  *
  * @group Data
  */
@@ -246,6 +246,91 @@ export interface FindResult<M extends Record<string, unknown> = Record<string, u
     meta: PaginationMeta;
 }
 
+/**
+ * Which column an iteration seeks on, for keyset ("seek") pagination.
+ *
+ * Either the column name on its own — sorted ascending — or the column plus an
+ * explicit direction. The column must be **unique** and must be the column the
+ * query is ordered by; see {@link PageWalkOptions.cursor}.
+ *
+ * @group Data
+ */
+export type CursorSpec<M extends Record<string, unknown> = Record<string, unknown>> =
+    | (Extract<keyof M, string>)
+    | { field: Extract<keyof M, string>; direction?: "asc" | "desc" };
+
+/**
+ * How {@link SDKCollectionClient.iterate} / {@link SDKCollectionClient.findAll}
+ * walk a collection, layered on top of the normal `find()` parameters.
+ *
+ * @group Data
+ */
+export interface PageWalkOptions<M extends Record<string, unknown> = Record<string, unknown>> {
+    /**
+     * Rows fetched per request. Defaults to 200; values below 1 are clamped up.
+     * This is the request size, not a result cap — the iteration keeps going
+     * until the server says there is nothing left.
+     */
+    pageSize?: number;
+    /**
+     * Paginate by **seeking on a column** instead of by offset.
+     *
+     * Offset paging — the default — re-counts rows on every request, so a row
+     * inserted or deleted *while the iteration runs* shifts the window and the
+     * walk silently skips or repeats rows. Seeking is immune to that: each page
+     * asks for rows strictly after the last one seen, so concurrent writes
+     * before the cursor cannot move it.
+     *
+     * Prefer this whenever the collection has a unique, sortable column
+     * (typically its primary key). The column must be unique — a repeated value
+     * at a page boundary either skips rows or stalls, and the iterator throws
+     * rather than looping — and the query is ordered by it, so a `cursor` and a
+     * conflicting `orderBy` is an error, not a silent override.
+     *
+     * Implemented with the parameters `find()` already takes (an `orderBy` plus
+     * a `>` / `<` filter on the cursor column), so it works on every transport
+     * and needs nothing new from the server.
+     *
+     * @example
+     * for await (const job of client.data.jobs.iterate({ cursor: "id" })) { … }
+     */
+    cursor?: CursorSpec<M>;
+    /**
+     * Hard ceiling on the number of requests one walk may make, so a server
+     * that never stops saying `hasMore` cannot spin forever. Defaults to
+     * 10 000 pages; hitting it throws.
+     */
+    maxPages?: number;
+}
+
+/**
+ * Parameters accepted by {@link SDKCollectionClient.iterate} — everything
+ * `find()` takes except the window itself (`limit`, `offset`, `page`), which
+ * the iterator owns, plus the walk options.
+ *
+ * @group Data
+ */
+export type IterateParams<M extends Record<string, unknown> = Record<string, unknown>> =
+    Omit<FindParams<M>, "limit" | "offset" | "page"> & PageWalkOptions<M>;
+
+/**
+ * Parameters accepted by {@link SDKCollectionClient.findAll}: the iteration
+ * parameters plus the ceiling that keeps a whole collection from being pulled
+ * into memory unnoticed.
+ *
+ * @group Data
+ */
+export type FindAllParams<M extends Record<string, unknown> = Record<string, unknown>> =
+    IterateParams<M> & {
+        /**
+         * Most rows to materialise. Defaults to 10 000. Exceeding it **throws**
+         * — a truncated array returned as if it were the whole answer is the
+         * kind of quiet wrong that shows up months later in a report. Pass
+         * `Infinity` to opt out deliberately, or use `iterate()` to stream.
+         */
+        maxRows?: number;
+    };
+
 /**
  * Fluent Query Builder Interface for the SDK client.
  * Returns `FindResult<M>` (flat rows) instead of `FindResponse<M>` (Entity-wrapped).
@@ -269,7 +354,7 @@ export interface SDKQueryBuilderInterface<M extends Record<string, unknown> = Re
  * SDK collection client — returns flat rows, no Entity wrapper.
  *
  * This is the public API surface for app developers using
- * `createRebaseClient()`. CMS internals use `CollectionAccessor` instead.
+ * `createRebaseClient()`. admin internals use `CollectionAccessor` instead.
  *
  * Type parameters:
  * - `M` — the **Row** shape returned by reads (`find`, `findById`, `listen`).
@@ -321,6 +406,67 @@ export interface SDKCollectionClient<
      */
     find(params?: FindParams<M>): Promise<FindResult<M>>;
 
+    /**
+     * Walk every record matching a query, one row at a time, fetching pages as
+     * the consumer consumes them.
+     *
+     * This is the pagination primitive: `find()` returns one window, `iterate()`
+     * returns all of them without the caller hand-rolling the
+     * `limit` / `offset += ` / "am I done yet" loop. Nothing is buffered — rows
+     * are yielded as each page arrives, so a million-row walk costs one page of
+     * memory. `break` stops the walk and no further requests are made.
+     *
+     * Termination is driven by the server's `meta.hasMore`, never by comparing
+     * a page's length against the requested limit — a final page that happens
+     * to be exactly full is indistinguishable that way, and a walk that stops
+     * there drops rows. An empty page also ends the walk, and
+     * {@link PageWalkOptions.maxPages} bounds a server that never stops saying
+     * there is more.
+     *
+     * ## Consistency
+     *
+     * By default this pages by **offset**, which is only as stable as the table
+     * is still: a row inserted or deleted ahead of the cursor between two
+     * requests shifts every later window, so the walk can skip a row or hand
+     * back the same one twice. That is inherent to offset paging, not a bug
+     * here. On a collection with a unique sortable column, pass
+     * {@link PageWalkOptions.cursor} to seek on it instead — the walk then
+     * asks for rows strictly after the last one it saw, which concurrent writes
+     * cannot perturb.
+     *
+     * @example
+     * for await (const job of client.data.jobs.iterate({
+     *     where: { status: ["==", "queued"] },
+     *     cursor: "id",
+     *     pageSize: 500
+     * })) {
+     *     await handle(job);
+     * }
+     */
+    iterate(params?: IterateParams<M>): AsyncIterableIterator<M>;
+
+    /**
+     * {@link iterate}, collected into an array.
+     *
+     * Convenient when the result is known to be small and awkward to stream.
+     * Because "known to be small" is an assumption and not a fact, the result is
+     * capped — 10 000 rows by default — and going over the cap **throws**
+     * rather than returning a short array that reads like a complete one. Raise
+     * {@link FindAllParams.maxRows} when the data really is bigger, or switch to
+     * `iterate()` and stream it.
+     *
+     * The offset-drift caveat on {@link iterate} applies here too.
+     *
+     * @throws When more rows match than `maxRows` allows.
+     *
+     * @example
+     * const overdue = await client.data.invoices.findAll({
+     *     where: { due_at: ["<", today] },
+     *     cursor: "id"
+     * });
+     */
+    findAll(params?: FindAllParams<M>): Promise<M[]>;
+
     /**
      * Find a single record by its ID.
      */
@@ -406,16 +552,16 @@ export interface SDKCollectionClient<
 }
 
 /**
- * The unified data access object for the **admin CMS** (Entity-shaped).
+ * The unified data access object for the **admin admin** (Entity-shaped).
  *
  * Access collections as dynamic properties: `data.products.find(...)`. Each
  * accessor returns `Entity`-wrapped records (`{ id, path, values }`) — the
- * view-model the CMS renders. This is what `useData()` / the admin
+ * view-model the admin renders. This is what `useData()` / the admin
  * `RebaseContext.data` are backed by.
  *
  * @internal App developers do **not** use this — they use
  * {@link RebaseSdkData} (flat rows), which is what the SDK client and backend
- * `context.data` expose. This Entity-shaped map backs the admin CMS only.
+ * `context.data` expose. This Entity-shaped map backs the admin admin only.
  *
  * @group Data
  */
@@ -455,7 +601,7 @@ export type RebaseData<DB = unknown> = {
  *
  * Every accessor returns flat rows (the table's columns) via
  * {@link SDKCollectionClient} — access fields directly (`row.title`), never
- * `row.values.title`. The admin CMS uses {@link RebaseData} (Entity) instead.
+ * `row.values.title`. The admin uses {@link RebaseData} (Entity) instead.
  *
  * @example
  * // Frontend SDK

package/src/types/admin_block.ts

@@ -73,3 +73,51 @@ export const ADMIN_COLLECTION_KEYS = [
 
 /** A key of a collection's `admin` block. @group Models */
 export type AdminCollectionKey = typeof ADMIN_COLLECTION_KEYS[number];
+
+/**
+ * Every key that belongs inside a *property's* `admin` block, as data.
+ *
+ * The union of `AdminPropertyOptions` and its per-type extensions
+ * (`AdminStringOptions`, `AdminArrayOptions`, …) in `@rebasepro/admin-types`.
+ * It lives here for the same reason {@link ADMIN_COLLECTION_KEYS} does: the
+ * runtime consumers are core packages that the BaaS guard forbids from
+ * importing `@rebasepro/admin-types`. Here it is the boot-time collection
+ * validator in `@rebasepro/server`, which has to tell "you left `readOnly` at
+ * the top of the property, where nothing reads it" apart from "you invented a
+ * key we have never heard of".
+ *
+ * `@rebasepro/admin-types` re-exports this and asserts it names only real
+ * option keys.
+ *
+ * @group Models
+ */
+export const ADMIN_PROPERTY_KEYS = [
+    "canAddElements",
+    "clearable",
+    "columnWidth",
+    "customProps",
+    "disabled",
+    "expanded",
+    "Field",
+    "Filter",
+    "filterOperators",
+    "fixedFilter",
+    "hideFromCollection",
+    "includeEntityLink",
+    "includeId",
+    "markdown",
+    "minimalistView",
+    "multiline",
+    "Preview",
+    "previewAsTag",
+    "previewProperties",
+    "readOnly",
+    "sortable",
+    "spreadChildren",
+    "urlPreview",
+    "widget",
+    "widthPercentage"
+] as const;
+
+/** A key of a property's `admin` block. @group Models */
+export type AdminPropertyKey = typeof ADMIN_PROPERTY_KEYS[number];

package/src/types/api_keys.ts

@@ -1,16 +1,56 @@
-/** A single permission entry scoping an API key to a collection and its allowed operations. */
+/**
+ * Service API keys — machine-to-machine authentication for scripts, cron jobs
+ * and third-party integrations.
+ *
+ * The wire contract lives here because all three sides need it and used to
+ * declare it separately: `@rebasepro/server` implements the routes,
+ * `@rebasepro/client` calls them, and {@link ApiKeysAPI} types the SDK surface.
+ * The client's copy had already drifted — it never gained `admin`.
+ *
+ * The database row itself (`ApiKey`, which carries `key_hash`) stays in the
+ * server package: nothing off the server may see it.
+ */
+
+/**
+ * A single permission entry scoping an API key to a collection and set of
+ * operations.
+ *
+ * Use `"*"` as the collection value to grant access to all collections (and all
+ * custom functions). Custom functions are addressed with the `functions`
+ * namespace: `"functions"` grants every function, `"functions/<name>"` grants a
+ * single one.
+ *
+ * @group Models
+ */
 export interface ApiKeyPermission {
+    /** Collection slug, `"functions"`/`"functions/<name>"`, or `"*"` for everything. */
     collection: string;
+    /** Allowed operations on the collection. */
     operations: ("read" | "write" | "delete")[];
 }
 
-/** An API key with the secret portion masked (returned by list / get / update). */
+/**
+ * An API key with the secret portion masked — what list / get / update return.
+ * @group Models
+ */
 export interface ApiKeyMasked {
     id: string;
     name: string;
+    /** First 12 characters of the plaintext key, for display only. */
     key_prefix: string;
     permissions: ApiKeyPermission[];
+    /**
+     * When true, the key is granted the `admin` role: it passes the admin-gated
+     * routes (users, roles, cron, backups, logs, API keys) and the RLS
+     * `default_admin` policies. Non-admin keys carry only the `service` role —
+     * RLS grants them nothing unless a collection policy names that role.
+     */
     admin: boolean;
+    /**
+     * Requests per 15-minute window. `null` means "no per-key override" — the
+     * data rate limiter then applies its default API-key limit (1000/window
+     * unless configured otherwise), not unlimited.
+     */
     rate_limit: number | null;
     created_by: string;
     created_at: string;
@@ -20,29 +60,45 @@ export interface ApiKeyMasked {
     revoked_at: string | null;
 }
 
-/** An API key including the full secret (returned only on creation). */
+/**
+ * Returned exactly once, when a key is created. The `key` field holds the full
+ * plaintext key — it is never stored or returned again.
+ * @group Models
+ */
 export interface ApiKeyWithSecret extends ApiKeyMasked {
+    /** Full plaintext API key (e.g. `rk_live_abc123...`). */
     key: string;
 }
 
-/** Payload for creating a new API key. */
+/**
+ * Payload for creating a new API key.
+ * @group Models
+ */
 export interface CreateApiKeyRequest {
     name: string;
     permissions: ApiKeyPermission[];
+    /** When true, grants the `admin` role. See {@link ApiKeyMasked.admin}. */
     admin?: boolean;
+    /** Requests per 15-minute window. Omit or `null` for the server default. */
     rate_limit?: number | null;
+    /** ISO-8601 expiration timestamp. Omit for no expiration. */
     expires_at?: string | null;
 }
 
-/** Payload for updating an existing API key. */
+/**
+ * Payload for updating an existing API key. Only the fields provided change.
+ * @group Models
+ */
 export interface UpdateApiKeyRequest {
     name?: string;
     permissions?: ApiKeyPermission[];
+    /** When true, grants the `admin` role. See {@link ApiKeyMasked.admin}. */
     admin?: boolean;
     rate_limit?: number | null;
     expires_at?: string | null;
 }
 
+/** @group Models */
 export interface ApiKeysAPI {
     listKeys(): Promise<{ keys: ApiKeyMasked[] }>;
     getKey(id: string): Promise<{ key: ApiKeyMasked }>;

package/src/types/collections.ts

@@ -5,6 +5,7 @@ import type { EnumValues, Properties, PostgresProperties, FirebaseProperties, Mo
 import type { User } from "../users";
 import type { Relation } from "./relations";
 import type { SecurityRule } from "./security_rules";
+import { getDataSourceCapabilities } from "./data_source";
 import type { WhereFilterOp, FilterValues, FilterPreset } from "./filter-operators";
 
 /**
@@ -116,30 +117,34 @@ export interface BaseCollectionConfig<M extends Record<string, unknown> = Record
      */
     auth?: boolean | AuthCollectionConfig;
 
-    /**
-     * Opt out of the framework's default Row Level Security policies.
-     *
-     * The schema generator automatically injects, for every collection, a
-     * baseline SELECT policy granting the trusted server context and the
-     * `admin` role read access (reads run under a restricted role, so RLS
-     * default-denies without it). For auth collections it additionally injects
-     * a self-read policy (`id = auth.uid()`) and an admin-only write gate
-     * (INSERT/UPDATE/DELETE require the `admin` role or the trusted server
-     * context), making privileged columns such as `roles` safe by default.
-     *
-     * Author-defined `securityRules` are permissive and broaden access on top
-     * of these defaults. Set this flag to `true` to remove the defaults
-     * entirely and take full responsibility for the collection's RLS.
-     *
-     * @default false
-     */
-    disableDefaultPolicies?: boolean;
 
 
 
 
 
 
+    /**
+     * Row-level authorization rules for this collection.
+     *
+     * Driver-agnostic on purpose, unlike `disableDefaultPolicies`, `table` and
+     * `relations`, which are declared on {@link PostgresCollectionConfig} only.
+     * The rules are a *contract* — who may read or write which rows — and each
+     * engine enforces it its own way:
+     *
+     * - **Postgres** compiles them to real `CREATE POLICY` statements and lets
+     *   the database enforce them (see {@link PostgresCollectionConfig.securityRules},
+     *   which narrows this with the raw-SQL details).
+     * - **MongoDB** translates them into a query filter it AND-s into every
+     *   read and write, honouring `access`, `ownerField`, `roles`, `mode` and
+     *   the `operation`/`operations` selectors, and making a best effort at raw
+     *   `using`/`withCheck` SQL.
+     * - **Firestore** does not implement them at all; its own rules language is
+     *   evaluated by Google, not from here. `supportsRLS` on
+     *   {@link DataSourceCapabilities} reports which engines generate policies,
+     *   which is not the same question as whether an engine honours a rule.
+     */
+    securityRules?: readonly SecurityRule[];
+
     /**
      * This interface defines all the callbacks that can be used when a entity
      * is being created, updated or deleted.
@@ -202,26 +207,6 @@ export interface BaseCollectionConfig<M extends Record<string, unknown> = Record
 
 
 
-    /**
-     * The database table name for this collection.
-     * Automatically set for PostgreSQL collections.
-     * For non-SQL backends, this may be undefined.
-     */
-    table?: string;
-
-    /**
-     * Relations defined for this collection.
-     * Populated at normalization time from inline relation properties
-     * or explicit relation definitions.
-     */
-    relations?: Relation[];
-
-    /**
-     * Security rules for this collection (Row Level Security).
-     * When defined, the backend enforces access control policies.
-     */
-    securityRules?: readonly SecurityRule[];
-
 }
 
 // ── Driver-specific collection types ──────────────────────────────────
@@ -279,6 +264,25 @@ export interface PostgresCollectionConfig<M extends Record<string, unknown> = Re
      * - `auth.jwt()`   — full JWT claims as JSONB
      */
     securityRules?: readonly SecurityRule[];
+
+    /**
+     * Opt out of the framework's default Row Level Security policies.
+     *
+     * The schema generator automatically injects, for every collection, a
+     * baseline SELECT policy granting the trusted server context and the
+     * `admin` role read access (reads run under a restricted role, so RLS
+     * default-denies without it). For auth collections it additionally injects
+     * a self-read policy (`id = auth.uid()`) and an admin-only write gate
+     * (INSERT/UPDATE/DELETE require the `admin` role or the trusted server
+     * context), making privileged columns such as `roles` safe by default.
+     *
+     * Author-defined `securityRules` are permissive and broaden access on top
+     * of these defaults. Set this flag to `true` to remove the defaults
+     * entirely and take full responsibility for the collection's RLS.
+     *
+     * @default false
+     */
+    disableDefaultPolicies?: boolean;
 }
 
 /**
@@ -404,7 +408,6 @@ export type CollectionConfig<M extends Record<string, unknown> = Record<string,
  *
  * @group Models
  */
-// eslint-disable-next-line @typescript-eslint/no-explicit-any
 export type AnyCollectionConfig = CollectionConfig<any, any>;
 
 /**
@@ -425,6 +428,32 @@ export function isPostgresCollectionConfig<C extends CollectionConfig<any, any>>
     return !collection.engine || collection.engine === "postgres";
 }
 
+/**
+ * Narrows to the SQL collection fields — `table`, `relations`,
+ * `disableDefaultPolicies` — by asking the engine's declared capabilities
+ * rather than by naming Postgres.
+ *
+ * The two halves of this already existed and were never joined. The engine
+ * split (`PostgresCollectionConfig` / `FirebaseCollectionConfig` /
+ * `MongoDBCollectionConfig`) said which fields belong to which engine at the
+ * type level; {@link DataSourceCapabilities} said the same thing at runtime,
+ * down to a `supportsRelations` flag. So call sites guarded on the capability
+ * and then read a field the base type had to declare for them — which is why
+ * those fields were on the base, and why a MongoDB collection could be written
+ * with a `table`.
+ *
+ * Prefer this over {@link isPostgresCollectionConfig} wherever the question is
+ * "does this collection live in a SQL table", so a custom SQL engine
+ * registered through `registerDataSourceCapabilities` is included.
+ *
+ * @group Models
+ */
+export function isRelationalCollectionConfig<C extends CollectionConfig<any, any>>(
+    collection: C
+): collection is C & PostgresCollectionConfig<any, any> {
+    return getDataSourceCapabilities(collection.engine).supportsRelations;
+}
+
 /**
  * Type guard for Firebase / Firestore collections.
  * @group Models

package/src/types/data_source.ts

@@ -4,7 +4,7 @@ import { ALL_WHERE_FILTER_OPS, WhereFilterOp } from "./filter-operators";
  * Describes the capabilities and features supported by a data source (driver).
  *
  * Each driver (Postgres, Firebase, MongoDB, etc.) declares which features it
- * supports. The CMS uses this descriptor to:
+ * supports. The admin uses this descriptor to:
  * - Show/hide editor tabs (e.g. Relations for SQL, Subcollections for Firebase)
  * - Filter the property type picker (e.g. `relation` for SQL, `reference` for Firebase)
  * - Toggle driver-specific form controls (e.g. `columnType` for SQL)
@@ -37,6 +37,17 @@ export interface DataSourceCapabilities {
     /** Does this source support real-time listeners? */
     supportsRealtime: boolean;
 
+    /**
+     * Does this source store vectors natively?
+     *
+     * `VectorProperty` carries a `dimensions` and is pgvector-shaped. It was
+     * the one driver-specific property kind with no flag to gate it, so unlike
+     * every other field in this descriptor there was not even a runtime answer
+     * to appeal to — a Firestore collection could declare an embedding column
+     * and no driver would do anything with it.
+     */
+    supportsVectors: boolean;
+
     /**
      * Canonical filter operators this engine can execute.
      *
@@ -48,6 +59,28 @@ export interface DataSourceCapabilities {
      */
     filterOperators: readonly WhereFilterOp[];
 
+    /**
+     * Relation kinds this engine's driver can compile into a filter.
+     *
+     * Only `belongsTo` puts a column on the row being filtered; the others are
+     * answered with a correlated subquery over the junction or the target
+     * table, which not every driver can build. An engine with no relations at
+     * all declares none.
+     *
+     * The admin uses this to decide whether a relation column offers a filter
+     * control. Offering one an engine cannot answer is not cosmetic: a driver
+     * that drops the key it cannot resolve *widens* the read to every row, and
+     * one that fails closed answers a control the admin itself put on screen
+     * with a 400.
+     *
+     * Optional, so a third-party driver registered before this existed still
+     * compiles. Omitted means {@link DEFAULT_FILTERABLE_RELATION_KINDS} — the
+     * one kind that is a plain column comparison, which every relational
+     * driver can do. The subquery kinds are a real capability and have to be
+     * claimed rather than assumed: assuming them wrongly is the widening.
+     */
+    filterableRelationKinds?: readonly string[];
+
     // ── Admin capability flags ───────────────────────────────────────
     /** Does this source support SQL admin operations (SQL editor, EXPLAIN, etc.)? */
     supportsSQLAdmin: boolean;
@@ -152,6 +185,17 @@ export interface ResolvedDataSource {
     capabilities: DataSourceCapabilities;
 }
 
+/**
+ * Relation kinds assumed filterable when a driver does not say.
+ *
+ * `belongsTo` alone: its filter is a comparison on a column of the row being
+ * filtered, the one shape that needs no query construction a driver might not
+ * have. Everything else is a correlated subquery over another table.
+ *
+ * @group Models
+ */
+export const DEFAULT_FILTERABLE_RELATION_KINDS: readonly string[] = ["belongsTo"];
+
 // ── Built-in driver capabilities ─────────────────────────────────────
 
 /** @group Models */
@@ -164,7 +208,11 @@ export const POSTGRES_CAPABILITIES: DataSourceCapabilities = {
     supportsReferences: false,
     supportsColumnTypes: true,
     supportsRealtime: true,
+    supportsVectors: true,
     filterOperators: ALL_WHERE_FILTER_OPS,
+    // `via` is absent: its join path is authored source → target with no
+    // stated inverse, so the driver has nothing to reverse into a filter.
+    filterableRelationKinds: ["belongsTo", "manyToMany", "hasMany", "hasOne"],
     supportsSQLAdmin: true,
     supportsDocumentAdmin: false,
     supportsSchemaAdmin: true
@@ -180,10 +228,13 @@ export const FIREBASE_CAPABILITIES: DataSourceCapabilities = {
     supportsReferences: true,
     supportsColumnTypes: false,
     supportsRealtime: true,
+    supportsVectors: false,
     // Firestore has no SQL pattern matching — the driver throws on the LIKE
     // family, so the UI must never offer it.
     filterOperators: ALL_WHERE_FILTER_OPS.filter(op =>
         op !== "like" && op !== "ilike" && op !== "not-like" && op !== "not-ilike"),
+    // No relations at all — a document store links by reference.
+    filterableRelationKinds: [],
     supportsSQLAdmin: false,
     supportsDocumentAdmin: false,
     supportsSchemaAdmin: false
@@ -199,7 +250,9 @@ export const MONGODB_CAPABILITIES: DataSourceCapabilities = {
     supportsReferences: true,
     supportsColumnTypes: false,
     supportsRealtime: false,
+    supportsVectors: false,
     filterOperators: ALL_WHERE_FILTER_OPS,
+    filterableRelationKinds: [],
     supportsSQLAdmin: false,
     supportsDocumentAdmin: true,
     supportsSchemaAdmin: true
@@ -219,7 +272,13 @@ export const DEFAULT_CAPABILITIES: DataSourceCapabilities = {
     supportsReferences: true,
     supportsColumnTypes: true,
     supportsRealtime: true,
+    supportsVectors: true,
     filterOperators: ALL_WHERE_FILTER_OPS,
+    // The exception to this descriptor's "enable everything" rule. The other
+    // flags hide a tab or a picker when they are wrong; this one decides
+    // whether a query is sent that an unknown driver may answer by dropping
+    // the condition — which returns every row rather than none.
+    filterableRelationKinds: DEFAULT_FILTERABLE_RELATION_KINDS,
     supportsSQLAdmin: true,
     supportsDocumentAdmin: true,
     supportsSchemaAdmin: true