import type { D1DatabaseLike, D1PreparedStatement, D1Result } from './d1.js';
export interface D1HttpConfig {
    accountId: string;
    databaseId: string;
    /** Cloudflare API token with the `D1:Edit` permission. */
    apiToken: string;
    /** Override for testing. */
    baseUrl?: string;
}
/**
 * A `D1DatabaseLike` implementation backed by Cloudflare's D1 REST API.
 *
 * This exists so `npm run db:migrate:remote` can run the *same* Kysely migrations against a
 * deployed D1 database from a laptop or CI, with no Worker involved. Keeping one migration source
 * of truth is the point: the alternative is maintaining a parallel set of `.sql` files for
 * `wrangler d1 migrations apply` and hoping the two never drift.
 *
 * Intended for CLI use only — inside a Worker, use the real binding, which is faster and needs no
 * API token.
 */
export declare class D1HttpDatabase implements D1DatabaseLike {
    #private;
    constructor(config: D1HttpConfig);
    prepare(sql: string): D1PreparedStatement;
    /**
     * Not atomic, unlike the real binding's `batch()`.
     *
     * The REST API has no batch endpoint that accepts per-statement parameters, so this runs
     * sequentially. That is fine for the only caller — the migration CLI, which runs statements one
     * at a time anyway because `D1Adapter` reports `supportsTransactionalDdl: false`. Application
     * code must never reach this path; it uses the binding, where `batch()` is genuinely atomic.
     */
    batch<T = unknown>(statements: D1PreparedStatement[]): Promise<D1Result<T>[]>;
}