@rebasepro/server-postgres 0.9.1-canary.1d2d8b5 → 0.9.1-canary.5809e39

package/dist/schema/doctor.d.ts

@@ -2,7 +2,7 @@ import { CollectionConfig, Property } from "@rebasepro/types";
 export type IssueSeverity = "error" | "warning" | "info";
 export interface DoctorIssue {
     severity: IssueSeverity;
-    category: "missing_table" | "missing_column" | "type_mismatch" | "missing_constraint" | "schema_stale" | "missing_enum" | "enum_value_mismatch" | "missing_foreign_key" | "sdk_stale";
+    category: "missing_table" | "missing_column" | "type_mismatch" | "missing_constraint" | "schema_stale" | "missing_enum" | "enum_value_mismatch" | "missing_foreign_key" | "sdk_stale" | "sdk_not_generated";
     table?: string;
     column?: string;
     expected?: string;

package/dist/services/FetchService.d.ts

@@ -40,44 +40,22 @@ export declare class FetchService {
      * the target relation so actual row data is returned.
      */
     private buildWithConfig;
-    /**
-     * Detect if a many-to-many relation uses a junction table in the Drizzle schema.
-     */
-    private isJunctionRelation;
     /**
      * Get the Drizzle relation name on the junction table that points to the actual target row.
      * For example, for posts_tags junction, this returns "tag_id" (the relation pointing to tags).
      */
     private getJunctionTargetRelationName;
-    /**
-     * Convert a db.query result row (with nested relation objects) to a flat row.
-     * Handles:
-     * - Placing `id` at the top level as a string
-     * - Type normalization (dates, numbers, NaN) via normalizeDbValues
-     * - Converting nested relation objects to { id, path, __type: "relation" } for CMS
-     * - Flattening junction-table many-to-many results
-     */
-    private drizzleResultToRow;
     /**
      * Post-fetch joinPath relations for a single flat row.
      * joinPath relations cannot be expressed via Drizzle's `with` config,
      * so they must be loaded separately after the primary query.
      */
     private resolveJoinPathRelations;
-    /**
-     * Post-fetch joinPath relations for a batch of flat rows.
-     * Uses batch fetching to avoid N+1 queries for list views.
-     */
-    private resolveJoinPathRelationsBatch;
     /**
      * Resolves joinPath relations for raw REST rows and directly injects them.
      * Uses RelationService to query the database and maps results back to the flattened objects.
      */
     private resolveJoinPathRelationsBatchRest;
-    /**
-     * Convert a db.query result row to a flat REST-style object with populated relations.
-     */
-    private drizzleResultToRestRow;
     /**
      * Build db.query-compatible options from standard fetch options.
      * Handles filter, search, orderBy, limit, and cursor-based pagination.
@@ -108,8 +86,10 @@ export declare class FetchService {
     }): Promise<Record<string, unknown>[]>;
     /**
      * Fallback path used when db.query is unavailable.
-     * The primary path uses drizzleResultToRow which handles relation
-     * mapping without N+1 queries.
+     *
+     * The primary path runs the results through `toCmsRow`, which maps
+     * relations from what drizzle already nested — no query per row. This one
+     * has no nesting to read, so it resolves relations itself, in batches.
      *
      * Process raw database results into flat rows with relations.
      */

package/dist/services/PersistService.d.ts

@@ -40,8 +40,16 @@ export declare class PersistService {
     deleteAll(collectionPath: string, _databaseId?: string): Promise<void>;
     /**
      * Save an row (create or update)
+     *
+     * With `options.upsert`, the row is written with INSERT ... ON CONFLICT DO
+     * UPDATE against the primary key rather than a plain UPDATE. That is one
+     * statement, so it cannot lose a race the way a read-then-write can, and it
+     * does not care whether the row already exists — which is what a re-runnable
+     * import needs.
      */
-    save<M extends Record<string, unknown>>(collectionPath: string, values: Partial<M>, id?: string | number, databaseId?: string): Promise<Record<string, unknown>>;
+    save<M extends Record<string, unknown>>(collectionPath: string, values: Partial<M>, id?: string | number, databaseId?: string, options?: {
+        upsert?: boolean;
+    }): Promise<Record<string, unknown>>;
     /**
      * Get the RelationService instance for external use
      */

package/dist/services/RelationService.d.ts

@@ -20,6 +20,40 @@ export declare class RelationService {
     private db;
     private registry;
     constructor(db: DrizzleClient, registry: PostgresCollectionRegistry);
+    /**
+     * One target row, as the {@link RelatedRow} everything here returns.
+     *
+     * Eight sites built this by hand, which is how the address came to be the
+     * target's first key column in all eight — one edit, eight places to miss.
+     *
+     * `resolveNested` is the one thing they did not agree on, and the
+     * disagreement was invisible: the single-parent fetches pass `db` and
+     * `registry` to `parseDataFromServer`, so the target's *own* relations get
+     * resolved too, while the batch paths deliberately do not — a query per
+     * target row is the N+1 the batching exists to avoid. Naming the parameter
+     * makes that a decision rather than a difference between two call sites
+     * nobody was comparing.
+     */
+    private toRelatedRow;
+    /**
+     * A WHERE matching any of `parentIds`, by the whole key.
+     *
+     * A single key is an `IN (…)`. A composite one cannot be: matching
+     * `tenant_id IN (1, 1)` collects every row of tenant 1, so two parents that
+     * share their first column each receive the other's relations. It becomes
+     * an OR of ANDs — one exact address per parent — which Postgres indexes the
+     * same way it would a multi-column key lookup.
+     */
+    private parentKeyCondition;
+    /**
+     * Reject a relation that cannot express a composite-keyed parent.
+     *
+     * `localKey` and `foreignKeyOnTarget` are single column names: one column
+     * cannot reference a two-column key, so such a relation has no correct
+     * reading. Left alone it would silently match on the first key column and
+     * hand a tenant's rows to its neighbour — say so instead.
+     */
+    private assertSingleKeyAddressable;
     /**
      * Fetch rows related to a parent row through a specific relation
      */
@@ -72,7 +106,6 @@ export declare class RelationService {
         relationKey: string;
         relation: Relation;
         newValue: unknown;
-        currentId?: string | number;
     }>): Promise<void>;
     /**
      * Handle inverse relations with joinPath

package/dist/services/collection-helpers.d.ts

@@ -1,6 +1,9 @@
 import { PgTable, AnyPgColumn } from "drizzle-orm/pg-core";
 import { CollectionConfig } from "@rebasepro/types";
 import { PostgresCollectionRegistry } from "../collections/PostgresCollectionRegistry";
+export { buildCompositeId, parseIdValues, COMPOSITE_ID_SEPARATOR } from "@rebasepro/common";
+export type { PrimaryKeyInfo } from "@rebasepro/common";
+import type { PrimaryKeyInfo } from "@rebasepro/common";
 /**
  * Shared helper functions for row operations.
  * These are used by FetchService, PersistService, and RelationService.
@@ -21,18 +24,80 @@ export interface DrizzleColumnMeta {
 export declare function getColumnMeta(col: AnyPgColumn): DrizzleColumnMeta;
 export declare function getCollectionByPath(collectionPath: string, registry: PostgresCollectionRegistry): CollectionConfig;
 export declare function getTableForCollection(collection: CollectionConfig, registry: PostgresCollectionRegistry): PgTable<any>;
-export declare function getPrimaryKeys(collection: CollectionConfig, registry: PostgresCollectionRegistry): {
-    fieldName: string;
-    type: "string" | "number";
-    isUUID?: boolean;
+/**
+ * The key columns a collection's rows are addressed by.
+ *
+ * Three tiers, in order: properties marked `isId`, the primary keys of the
+ * drizzle schema, and finally a column literally named `id`. Only the first is
+ * visible to the browser, which is why a key known only to drizzle is reported
+ * at boot — see {@link warnOnKeysTheAdminCannotResolve}.
+ *
+ * Returns `[]` when nothing resolves, rather than throwing. It used to open by
+ * resolving the table, which throws when there is none — so the `isId` tier,
+ * which needs no table at all, was unreachable for exactly the collections
+ * most likely to have no table registered. Every caller that wanted "no keys"
+ * to mean "no keys" had to spell that out in a try/catch.
+ *
+ * Callers that cannot proceed without a key must say so themselves, naming the
+ * collection: an empty array here means "this collection has no address", which
+ * is a different answer in a notification (broadcast a wildcard) than in a save
+ * (fail).
+ */
+export declare function getPrimaryKeys(collection: CollectionConfig, registry: PostgresCollectionRegistry): PrimaryKeyInfo[];
+/**
+ * The key columns, for callers that cannot do their job without one.
+ *
+ * {@link getPrimaryKeys} answers "what keys, if any" and returns `[]` for a
+ * collection with no address. Most of this driver, though, is building a WHERE
+ * clause and has no meaning without a key — for those, an empty array is not an
+ * answer, and indexing `[0]` into it produces `Cannot read properties of
+ * undefined` three frames from where the real problem is. This says what is
+ * wrong and which collection it is wrong about.
+ */
+export declare function requirePrimaryKeys(collection: CollectionConfig, registry: PostgresCollectionRegistry): PrimaryKeyInfo[];
+/**
+ * Collections whose key the *browser* cannot resolve, and what it will do
+ * instead.
+ *
+ * The two sides resolve keys from different evidence. This driver reads, in
+ * order: properties marked `isId`, the primary keys of the Drizzle schema, then
+ * a column literally named `id`. The admin shares the `CollectionConfig` — it
+ * compiles the same collection files into its bundle — but never the Drizzle
+ * schema, so the middle tier is invisible to it.
+ *
+ * Nothing can normalize this at runtime: the server does not serve the admin
+ * its collections, so a key resolved here cannot be handed over there. The
+ * config files are the only thing both sides read, so the fix is an edit to
+ * them, and the most this can do is say exactly which edit.
+ *
+ * Two shapes, and the second is the dangerous one:
+ *
+ * - No `isId`, no `id` property → the admin resolves no address, warns in the
+ *   console, and rows cannot be opened or linked.
+ * - No `isId`, but an `id` property that is *not* the key → the admin addresses
+ *   rows by `id` while this driver reads the address as the real key. Nothing
+ *   errors: the addresses look right and route wrong.
+ */
+export declare function findUnresolvableKeyCollections(collections: CollectionConfig[], registry: PostgresCollectionRegistry): {
+    collection: CollectionConfig;
+    keys: PrimaryKeyInfo[];
+    shadowedByIdProperty: boolean;
 }[];
-export declare function parseIdValues(idValue: string | number, primaryKeys: {
-    fieldName: string;
-    type: "string" | "number";
-    isUUID?: boolean;
-}[]): Record<string, string | number>;
-export declare function buildCompositeId(values: Record<string, unknown>, primaryKeys: {
-    fieldName: string;
-    type: "string" | "number";
-    isUUID?: boolean;
-}[]): string;
+/**
+ * Report the collections from {@link findUnresolvableKeyCollections} at boot,
+ * with the edit that fixes each one.
+ *
+ * Grouped by failure, not by collection: the shadowed case is a routing bug and
+ * the silent case is a missing feature, and they deserve different urgency.
+ */
+export declare function warnOnKeysTheAdminCannotResolve(collections: CollectionConfig[], registry: PostgresCollectionRegistry): void;
+/**
+ * The address of a row: derived from the collection's primary keys, because a
+ * row does not carry one — it is exactly its columns.
+ *
+ * Falls back to a literal `id` column, for a row that reached us from somewhere
+ * other than this driver. Returns `""` when there is no key and no `id` —
+ * callers decide what that means, since "unaddressable" is a different answer
+ * in a notification (broadcast a wildcard) than in a save (fail).
+ */
+export declare function deriveRowAddress(row: Record<string, unknown>, collection: CollectionConfig, registry: PostgresCollectionRegistry): string;

package/dist/services/dataService.d.ts

@@ -82,7 +82,9 @@ export declare class DataService implements DataRepository {
     /**
      * Save an row (create or update)
      */
-    save<M extends Record<string, unknown>>(collectionPath: string, values: Partial<M>, id?: string | number, databaseId?: string): Promise<Record<string, unknown>>;
+    save<M extends Record<string, unknown>>(collectionPath: string, values: Partial<M>, id?: string | number, databaseId?: string, options?: {
+        upsert?: boolean;
+    }): Promise<Record<string, unknown>>;
     /**
      * Delete an row by ID
      */

package/dist/services/index.d.ts

@@ -1,4 +1,4 @@
 export { FetchService } from "./FetchService";
 export { PersistService } from "./PersistService";
 export { RelationService } from "./RelationService";
-export { getCollectionByPath, getTableForCollection, getPrimaryKeys, parseIdValues, buildCompositeId } from "./collection-helpers";
+export { getCollectionByPath, getTableForCollection, getPrimaryKeys, deriveRowAddress, parseIdValues, buildCompositeId } from "./collection-helpers";

package/dist/services/realtimeService.d.ts

@@ -177,8 +177,15 @@ export declare class RealtimeService extends EventEmitter implements RealtimePro
     /**
      * Send a lightweight row-level patch to a collection subscriber.
      * The client can merge this into its cached data for instant feedback.
+     *
+     * The key columns ride along: the patch names a row by address, and the
+     * client has to find that row among the ones it cached — which carry
+     * columns and no address. The SDK holds no collection config to derive one
+     * from, so this is the only place the mapping can come from.
      */
     private sendCollectionPatch;
+    /** The key columns of the collection at `path`, if they can be resolved. */
+    private primaryKeysForPath;
     private sendError;
     private sendMessage;
     /**

package/dist/services/row-pipeline.d.ts

@@ -0,0 +1,63 @@
+import { CollectionConfig, Relation } from "@rebasepro/types";
+import { PostgresCollectionRegistry } from "../collections/PostgresCollectionRegistry";
+/**
+ * Turning a drizzle result into a row we serve.
+ *
+ * There are two shapes, and they are the same walk. Both take a row whose
+ * relation fields hold nested objects, both unwrap junction rows to reach the
+ * target behind them, and both leave every other column alone. They differ only
+ * in what they put where the relation was:
+ *
+ * - `"ref"` — a `{ id, path, __type: "relation" }` reference carrying the
+ *   target's values. This is what the admin renders.
+ * - `"inline"` — the target's own columns, flat. This is what REST serves.
+ *
+ * They used to be two functions that happened to agree, and the agreement was
+ * not enforced by anything: the row-identity bug had to be fixed five times
+ * across differently-shaped copies of this walk, and one of the copies was
+ * dead code nobody had noticed. Whatever the next cross-cutting change is, it
+ * is one edit here.
+ */
+export type RelationStyle = "ref" | "inline";
+/**
+ * Whether a many-relation reaches its target through a junction table.
+ *
+ * Also used to build the drizzle `with` config, which is why it is exported:
+ * the query has to nest one level deeper for a junction, and the row walk has
+ * to unwrap that same level back out.
+ */
+export declare function isJunctionRelation(relation: Relation): boolean;
+/**
+ * The address a relation ref points at.
+ *
+ * The whole key, not its first column: a composite-keyed target addressed by
+ * `tenant_id` alone points at every row that shares it. A target whose key
+ * cannot be resolved at all used to throw here — reading `[0]` of an empty
+ * array — taking down the parent's fetch over a relation it may not even have
+ * asked for. The first column is a guess, but a ref that resolves to nothing
+ * beats no rows at all.
+ */
+export declare function relationTargetAddress(targetRow: Record<string, unknown>, targetCollection: CollectionConfig, registry: PostgresCollectionRegistry): string;
+/**
+ * The row the admin renders: every column, with relations as references.
+ *
+ * Values are normalized (dates, numbers, NaN) because the admin's view-model
+ * expects real types. The row's own address is *not* among the columns — it is
+ * derived by the consumer from the collection's primary keys.
+ */
+export declare function toCmsRow(row: Record<string, unknown>, collection: CollectionConfig, registry: PostgresCollectionRegistry): Record<string, unknown>;
+/**
+ * The row REST serves: every column under its own name, with the value Postgres
+ * returned, and relations inlined as the target's columns.
+ *
+ * Values are the ones the database returned, except where that contradicts the
+ * declared type: a `number` property is served as a number (see
+ * {@link coerceDeclaredNumber}). Dates stay as the database returned them —
+ * JSON has its own opinions about dates that the admin's view-model does not
+ * share.
+ *
+ * Keyed by the row rather than by the relation list — a REST fetch only loads
+ * the relations `include` asked for, so the row is the authority on which are
+ * actually there.
+ */
+export declare function toRestRow(row: Record<string, unknown>, collection: CollectionConfig, registry: PostgresCollectionRegistry): Record<string, unknown>;

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@rebasepro/server-postgres",
   "type": "module",
-  "version": "0.9.1-canary.1d2d8b5",
+  "version": "0.9.1-canary.5809e39",
   "description": "PostgreSQL data source backend implementation for Rebase with Drizzle ORM",
   "funding": {
     "url": "https://github.com/sponsors/rebaseco"
@@ -69,21 +69,22 @@
     "dotenv": "^17.4.2",
     "drizzle-orm": "^0.45.2",
     "execa": "^9.6.1",
-    "hono": "^4.12.25",
     "pg": "^8.21.0",
     "ws": "^8.21.0",
-    "@rebasepro/codegen": "0.9.1-canary.1d2d8b5",
-    "@rebasepro/types": "0.9.1-canary.1d2d8b5",
-    "@rebasepro/server": "0.9.1-canary.1d2d8b5",
-    "@rebasepro/common": "0.9.1-canary.1d2d8b5",
-    "@rebasepro/utils": "0.9.1-canary.1d2d8b5"
+    "@rebasepro/codegen": "0.9.1-canary.5809e39",
+    "@rebasepro/common": "0.9.1-canary.5809e39",
+    "@rebasepro/server": "0.9.1-canary.5809e39",
+    "@rebasepro/types": "0.9.1-canary.5809e39",
+    "@rebasepro/utils": "0.9.1-canary.5809e39"
   },
   "devDependencies": {
+    "@hono/node-server": "^2.0.9",
     "@types/jest": "^30.0.0",
     "@types/node": "^25.9.3",
     "@types/pg": "^8.20.0",
     "@types/ws": "^8.18.1",
     "@vitejs/plugin-react": "^6.0.2",
+    "hono": "^4.12.25",
     "jest": "^30.4.2",
     "ts-jest": "^29.4.11",
     "typescript": "^6.0.3",
@@ -104,6 +105,7 @@
     "test:lint": "eslint \"src/**\" --quiet",
     "test": "jest --passWithNoTests",
     "test:e2e": "vitest run --config vitest.e2e.config.ts",
-    "clean": "rm -rf dist && find ./src -name '*.js' -type f | xargs rm -f"
+    "clean": "rm -rf dist && find ./src -name '*.js' -type f | xargs rm -f",
+    "smoke:baas": "tsx scripts/smoke-baas.ts"
   }
 }

package/src/PostgresBackendDriver.ts

@@ -17,6 +17,7 @@ import {
     RebaseData,
     RebaseSdkData,
     RestFetchService,
+    SaveManyProps,
     SaveProps,
     TableColumnInfo,
     TableForeignKeyInfo,
@@ -28,6 +29,7 @@ import {
 import { sql as drizzleSql } from "drizzle-orm";
 import { buildPropertyCallbacks, buildSdkData, resolveCollectionRelations, updateDateAutoValues } from "@rebasepro/common";
 import { PostgresCollectionRegistry } from "./collections/PostgresCollectionRegistry";
+import { deriveRowAddress } from "./services/collection-helpers";
 import { HistoryService } from "./history/HistoryService";
 import { mergeDeep } from "@rebasepro/utils";
 import { logger } from "@rebasepro/server";
@@ -532,7 +534,8 @@ export class PostgresBackendDriver implements DataDriver {
                                                             id,
                                                             values,
                                                             collection,
-                                                            status
+                                                            status,
+                                                            upsert
                                                         }: SaveProps<M>): Promise<Record<string, unknown>> {
 
         const {
@@ -545,13 +548,26 @@ export class PostgresBackendDriver implements DataDriver {
         let updatedValues = values;
         const contextForCallback = this.buildCallContext();
 
-        // Fetch previous values for callbacks AND history recording
+        // Fetch previous values for callbacks AND history recording. Same walk
+        // as the saved row the callbacks receive (`fetchOneForRest`), so
+        // `values` and `previousValues` compare like with like — a Date on one
+        // side and its ISO string on the other reads as a change that never
+        // happened.
         let previousValuesForHistory: Partial<M> | undefined;
         if (status === "existing" && id) {
-            const existing = await this.dataService.fetchOne<M>(path, id, resolvedCollection?.databaseId);
-            if (existing) {
-                const { id: _existingId, ...existingValues } = existing;
-                previousValuesForHistory = existingValues as Partial<M>;
+            try {
+                const existing = await this.dataService.getFetchService()
+                    .fetchOneForRest(path, id, undefined, resolvedCollection?.databaseId);
+                if (existing) {
+                    const { id: _existingId, ...existingValues } = existing;
+                    previousValuesForHistory = existingValues as Partial<M>;
+                }
+            } catch (err) {
+                // Best-effort enrichment: callbacks and history run without
+                // previous values rather than the save failing on a read the
+                // write itself does not need (e.g. a collection whose key the
+                // registry cannot resolve).
+                logger.debug(`[save] Could not fetch previous values for "${path}"`, { detail: err instanceof Error ? err.message : String(err) });
             }
         }
 
@@ -616,7 +632,8 @@ export class PostgresBackendDriver implements DataDriver {
                 path,
                 updatedValues,
                 id,
-                resolvedCollection?.databaseId
+                resolvedCollection?.databaseId,
+                { upsert }
             );
 
             if (savedRow && (globalCallbacks?.afterRead || callbacks?.afterRead || propertyCallbacks?.afterRead)) {
@@ -649,8 +666,19 @@ export class PostgresBackendDriver implements DataDriver {
                 }
             }
 
-            const savedId = savedRow.id as string | number;
-            const { id: _savedId, ...savedValues } = savedRow;
+            // The row is exactly its columns, so its address is derived, not read
+            // off it: `savedRow.id` is undefined for every table whose key is not
+            // literally named `id`, and is ordinary data for a table that has such
+            // a column without it being the key.
+            const savedId = deriveRowAddress(
+                savedRow,
+                (resolvedCollection ?? collection) as CollectionConfig,
+                this.registry
+            );
+            // `values` are the row's columns — all of them. For an `id`-keyed table
+            // that includes `id`, which used to be stripped here because it was the
+            // synthesized address rather than the column it now is.
+            const savedValues = savedRow;
 
             if (globalCallbacks?.afterSave || callbacks?.afterSave || propertyCallbacks?.afterSave) {
                 // 1. Global callbacks first
@@ -695,7 +723,7 @@ export class PostgresBackendDriver implements DataDriver {
             if (this.historyService && resolvedCollection?.history) {
                 this.historyService.recordHistory({
                     tableName: path,
-                    id: savedId.toString(),
+                    id: savedId,
                     action: status === "new" ? "create" : "update",
                     values: savedValues as Record<string, unknown>,
                     previousValues: previousValuesForHistory as Record<string, unknown> | undefined,
@@ -707,14 +735,14 @@ export class PostgresBackendDriver implements DataDriver {
             if (this._deferNotifications) {
                 this._pendingNotifications.push({
                     path,
-                    id: savedId.toString(),
+                    id: savedId,
                     row: savedRow,
                     databaseId: resolvedCollection?.databaseId
                 });
             } else {
                 await this.realtimeService.notifyUpdate(
                     path,
-                    savedId.toString(),
+                    savedId,
                     savedRow,
                     resolvedCollection?.databaseId
                 );
@@ -764,13 +792,86 @@ export class PostgresBackendDriver implements DataDriver {
         }
     }
 
+    /**
+     * Write many rows through the same pipeline as {@link save}.
+     *
+     * The batch runs in one transaction of its own, so a failure part-way leaves
+     * nothing behind — the point of a batch is that a re-run starts from a known
+     * state. When this driver is already inside a transaction (the authenticated
+     * path, via `withTransaction`) the nested call becomes a savepoint, which is
+     * still atomic and still commits once.
+     *
+     * Rows are applied in order, so a batch that touches the same key twice ends
+     * with the last write winning, exactly as separate calls would.
+     */
+    async saveMany<M extends Record<string, unknown>>({
+                                                          path,
+                                                          rows,
+                                                          collection,
+                                                          upsert
+                                                      }: SaveManyProps<M>): Promise<Record<string, unknown>[]> {
+        return this.db.transaction(async (tx) => {
+            // Bind the whole batch to the transaction handle. Without this the
+            // rows would be written through `this.db` and survive a rollback.
+            const txDriver = new PostgresBackendDriver(
+                tx, this.realtimeService, this.registry, this.user, this.poolManager, this.historyService
+            );
+            txDriver.dataService = new DataService(tx, this.registry);
+            txDriver.client = this.client;
+            // Carry the caller's notification batching through, so a bulk write
+            // nested in an outer transaction still holds its events until commit.
+            txDriver._deferNotifications = this._deferNotifications;
+            txDriver._pendingNotifications = this._pendingNotifications;
+
+            const saved: Record<string, unknown>[] = [];
+
+            for (let i = 0; i < rows.length; i++) {
+                const values = rows[i];
+                const id = (values as Record<string, unknown>)?.id as string | number | undefined;
+                try {
+                    saved.push(await txDriver.save<M>({
+                        path,
+                        values,
+                        // No `id` argument, deliberately: passing one selects the
+                        // UPDATE path, and an import's rows usually carry a natural
+                        // key for a row that does not exist yet — which would 404 on
+                        // every one. Leaving the key inside `values` is what
+                        // single-row `create(data, id)` does, and it inserts.
+                        // Callers who want existing rows overwritten pass `upsert`.
+                        collection,
+                        status: "new",
+                        upsert
+                    }));
+                } catch (error) {
+                    // One bad row in ten thousand is impossible to find from a
+                    // message that only says the batch failed. Say which row, and
+                    // keep the original error as the cause so its status survives.
+                    const label = id !== undefined ? `id ${JSON.stringify(id)}` : "no id";
+                    throw Object.assign(
+                        new Error(`Row ${i} of ${rows.length} (${label}) failed: ${(error as Error)?.message ?? error}`, { cause: error }),
+                        {
+                            statusCode: (error as { statusCode?: number })?.statusCode,
+                            code: (error as { code?: string })?.code,
+                            name: (error as Error)?.name
+                        }
+                    );
+                }
+            }
+
+            return saved;
+        });
+    }
+
     async delete<M extends Record<string, unknown>>({
                                                               row,
                                                               collection
                                                           }: DeleteProps<M>): Promise<void> {
 
         const targetPath = row.path;
-        const targetRow: Record<string, unknown> = { id: row.id, ...(row.values ?? {}) };
+        // The callbacks' `row` is the row: its columns, nothing else. The address
+        // travels beside it as `id`, so merging it in here only ever invented an
+        // `id` field for tables that have no such column.
+        const targetRow: Record<string, unknown> = { ...(row.values ?? {}) };
 
         // Resolve from backend registry to restore callbacks lost during WebSocket serialization
         const {
@@ -1362,6 +1463,19 @@ export class AuthenticatedPostgresBackendDriver implements DataDriver {
         return this.withTransaction((delegate) => delegate.save(props));
     }
 
+    /**
+     * One transaction for the whole batch, rather than one per row.
+     *
+     * This is the point of the method: `save` opens a transaction per call, so
+     * importing 10k rows through it means 10k transactions (and, over HTTP, 10k
+     * round trips). Here the RLS context is established once and every row lands
+     * or none does. Realtime notifications are already deferred to commit by
+     * `withTransaction`, so a batch does not flood subscribers mid-flight.
+     */
+    async saveMany<M extends Record<string, unknown>>(props: SaveManyProps<M>): Promise<Record<string, unknown>[]> {
+        return this.withTransaction((delegate) => delegate.saveMany(props));
+    }
+
     async delete<M extends Record<string, unknown>>(props: DeleteProps<M>): Promise<void> {
         return this.withTransaction((delegate) => delegate.delete(props));
     }