import type { LibSQLDatabase } from "drizzle-orm/libsql";
/**
 * Returns true when a SQL string starts with a SELECT-class verb.
 * Used by the Neon resilience wrapper to decide retry safety:
 *   - reads (SELECT) → retryable on any connection-class error
 *   - writes (INSERT/UPDATE/DELETE/…) → only retryable on errors that
 *     provably occurred BEFORE the statement was sent (e.g. an acquire /
 *     connect timeout). Post-send write failures must propagate to the caller
 *     to avoid double-execution.
 */
export declare function isSqlRead(sql: string): boolean;
/**
 * Wraps a @neondatabase/serverless Pool so every query goes through
 * the same withDbTimeout + retryOnConnectionError resilience that the
 * raw DbExec path in client.ts uses. This protects Drizzle queries
 * (which bypass DbExec) from the frozen-WebSocket failure mode documented
 * in client.ts (~lines 378–408).
 *
 * Retry-safety rule (prevents double-execution on writes):
 *   - Reads (SELECT / WITH …): retry freely on any connection-class error.
 *   - Writes: only retry when the error occurred during connection acquire
 *     (i.e. withDbTimeout "connect" timed out before the statement was ever
 *     sent). Post-send failures on writes are rethrown immediately.
 *
 * Transactions: we do NOT wrap individual queries inside a drizzle
 * transaction — drizzle-neon-serverless manages the session itself, so
 * interposing a per-query client acquire/release would break the sticky
 * connection the transaction needs. The pool-level error logger still fires
 * on idle-client drops inside transactions.
 */
export declare function buildResilientNeonPool<T extends {
    connect(): Promise<any>;
    query(...args: any[]): Promise<any>;
    end(): Promise<void>;
    on(event: string, listener: (...args: any[]) => void): unknown;
}>(pool: T): T;
/**
 * Wraps a postgres.js client so Drizzle queries on the non-Neon Postgres
 * path get the same withDbTimeout + retryOnConnectionError protection as
 * every other Postgres path (raw DbExec postgres.js, raw DbExec Neon, and
 * the Drizzle Neon pool above). Without this, one hung query on a BYO
 * Postgres deployment stalls its request forever.
 *
 * Drizzle's postgres-js session only calls `client.unsafe(query, params)` —
 * awaited directly for row-object results or via `.values()` for row-array
 * results — plus `client.begin(...)` for transactions. We interpose on
 * `unsafe` with a lazy thenable that re-issues the query per retry attempt,
 * and leave transactions unwrapped (same rule as the Neon wrapper: the
 * driver manages the sticky connection inside `begin`).
 *
 * Retry-safety mirrors buildResilientNeonPool: reads retry freely on
 * connection-class errors; writes retry only on CONNECT_TIMEOUT (postgres.js
 * raises it before the statement is ever sent), so writes can't
 * double-execute.
 */
export declare function buildResilientPostgresJsClient<T extends {
    unsafe(query: string, params?: any[], options?: any): any;
}>(client: T): T;
/**
 * Neon's pooler endpoints cold-start in 5–10s. Serverless environments
 * (Netlify Functions, Vercel Edge, CF Workers) have short cold-start
 * budgets of their own, and `postgres-js` opens a raw TCP connection on
 * port 5432 that can't negotiate around Neon's wake-up window — every
 * request after an idle period 502s. `@neondatabase/serverless` rides
 * over WebSockets (HTTP/443 upgrade) and handles Neon wake-up
 * transparently, supports transactions, and works in every serverless
 * runtime we deploy to, so we prefer it whenever the URL points at Neon.
 */
export declare function isNeonUrl(url: string): boolean;
/**
 * Patch a drizzle-orm/better-sqlite3 instance so that db.transaction(async …)
 * works. The native better-sqlite3 Transaction wrapper is sync-only — passing
 * an async callback throws "Transaction function cannot return a promise".
 *
 * This wrapper bypasses the native path by issuing raw SQL control statements
 * on the single better-sqlite3 connection, which is safe because:
 *   - better-sqlite3 is single-connection (no concurrency inside one process)
 *   - the framework serialises all async work through one Database instance
 *
 * Nesting: if a transaction is already open (sqlite.inTransaction === true),
 * SAVEPOINT / RELEASE / ROLLBACK TO is used instead of BEGIN / COMMIT /
 * ROLLBACK, matching drizzle's own BetterSQLiteTransaction.transaction().
 *
 * The patched transaction also patches the tx object it passes to the callback
 * so that nested async calls (tx.transaction(async …)) work recursively.
 */
/** @internal exported for the async-tx concurrency spec */
export declare function patchBetterSqliteTransactions<DB extends {
    transaction: (...args: any[]) => any;
    session: any;
}>(db: DB, sqlite: {
    inTransaction: boolean;
    exec: (sql: string) => void;
}): DB;
export declare function createGetDb<T extends Record<string, unknown>>(schema: T): () => LibSQLDatabase<T>;
//# sourceMappingURL=create-get-db.d.ts.map