Limits & Credits

Deltex meters everything with one unit: the credit. There are no separate line items for reads, writes, and compute — every plan includes a monthly credit allowance, and paid plans bill only for usage beyond it.

How credits are counted

So a read query is about 1 credit and a write query is about 2 (the statement plus the write). A run of 1,000 simple SELECTs costs roughly 1,000 credits; 1,000 inserts roughly 2,000. Compute-heavy analytical scans add a credit per CPU-second.

Plan allowances

When you hit a limit

• Free credit cap — the free tier is hard-capped. When you reach your monthly credits, requests return 429 until the allowance resets at the start of the next month. You are never billed overage on free.
• Paid overage — Pro and Scale keep serving past the included allowance and bill the overage at the rate above. There is no hard stop.
• Rate limit — exceeding your per-minute request rate returns 429 with a Retry-After header. This is independent of your credit balance.

Per-request limits

The 50 ms ceiling is the edge runtime's per-request CPU budget; the Server-Timing header on every response reports the vcpu time consumed so you can see how close a query runs to it. For very large result sets, stream them with the /*+ STREAM */ hint instead of buffering a single response.

Operational semantics — what to design around

These are architectural properties, not billing knobs. Designing with them in mind is the difference between a fast app and a slow one.

• One home region per tenant. Each database is homed in a single storage region (auto-selected at signup from where you sign up). Reads are served and cached at every edge location; durable writes always commit to the home region. Users far from the home region pay more write latency — place the database where your writers are.
• Durable by default. The default write mode waits for the storage commit before acknowledging — an acked write is never lost. edge and async modes acknowledge earlier in exchange for eventual durability; they're explicit opt-ins for caches, sessions, and telemetry, not for data you can't lose.
• Batch your writes. Every durable statement pays one commit round-trip. A multi-row INSERT or a /v1/transaction body coalesces many writes into approximately one commit — an order of magnitude faster than issuing statements one at a time. Looping single-row inserts is the most common performance mistake.
• A transaction is one request. Transactions are request-scoped: send all statements together and they commit atomically with serializable isolation. There are no interactive sessions — you cannot open BEGIN in one request and COMMIT in another, hold locks across requests, or use session-pinned state. This removes an entire class of distributed-transaction failure modes, but ORMs that expect connection-scoped transactions must use the request-scoped API instead.
• Concurrent-write conflicts retry, then surface. Writes are compare-and-swap protected. Under heavy concurrent writes to the same table the engine retries internally; if contention persists you receive a conflict error and should retry with backoff (the SDKs' transaction helpers do this).
• Storage quotas are enforced before writes. Byte and key quotas (per plan, above) are checked pre-write — the failure mode for an over-quota tenant is a clear quota error, not degraded behavior.