Databricks AI functions cost: ai_query, ai_parse_document

Run ai_parse_document over a folder of PDFs and the bill arrives in 2 places. One is the SQL warehouse that ran the query, by the hour, as for any other query. The other is the model work behind every page it read, priced by the page. The second line is the one teams miss, because it grows with your data rather than with how long the query runs.

What each kind of function adds

All AI functions run inside a query on your compute. They differ in what they add on top.

The last row is worth knowing. A forecast in SQL looks like a model call, but it runs on the warehouse you already pay for.

AI functions do not run on classic SQL warehouses at all. Run them from a serverless SQL warehouse, a notebook or job on Databricks Runtime 15.4 LTS or later, or a Lakeflow pipeline. The warehouse prices are in our Databricks cost calculator.

A worked month: 50,000 invoices

Take an accounts-payable team that receives 50,000 vendor invoices a month, 3 pages each. They want 3 fields from each one: the invoice number, the vendor and the total. Databricks publishes its estimates as DBUs per 1,000 pages or inputs, at $0.07 a DBU in AWS US East:

• Parsing. 150,000 pages of invoice-like layout, at 20 to 25 DBUs per 1,000 pages, comes to $210 to $262.50.
• Extraction. 50,000 documents, at 30 to 60 DBUs per 1,000 in standard mode, comes to $105 to $210.
• The warehouse. A Small serverless SQL warehouse (12 DBUs an hour at $0.70) running 10 hours a month costs $84.

The month comes to about $400 to $560. Now move the controls and see which line grows.

Try itA month of AI functions, as a bill

Documents a month

50000

Pages per document

3

What the pages look like

·Plain text (memos, contracts)·Invoices, ID documents·Complex tables (bank statements)·Dense forms, diagrams

Every pageFirst page only

OffStandardPrecision

OffOn

SmallMediumLarge

Warehouse hours a month

10 h

Usage this month

• ai_parse_document150,000 pages$210 to $263
• ai_extract50,000 documents$105 to $210
• ai_classify50,000 documents$140 to $210
• SQL warehouse, Small10 h serverless$84

Total$539 to $767

Two settings stand out when you play with it. Precision mode multiplies the extraction line by about 10. And parsing every page of a document when the fields you want are on page 1 multiplies the parse line by the page count.

4 settings that cut the inference line

Parse only the pages you need. pageRange takes page numbers or ranges, such as '1' or '1-2'. On the invoice example, parsing page 1 only takes the parse line from $210–$262.50 down to $70–$87.50.

Skip figure descriptions you will not read. By default the parser writes an AI-generated description of each figure. Setting descriptionElementTypes to an empty string switches that off, which reduces the compute and the cost for documents full of charts and diagrams.

Parse once, then work from the stored result. ai_extract and ai_classify cannot read files; they read the output of ai_parse_document. So store that output in a table and run every later step against the table, not against the PDFs:

-- Parse each new invoice once
INSERT INTO finance.ap.parsed_invoices
SELECT path,
       ai_parse_document(
         content,
         MAP('version', '2.0', 'pageRange', '1', 'descriptionElementTypes', '')
       ) AS parsed
FROM READ_FILES('/Volumes/finance/invoices/', format => 'binaryFile')
WHERE path NOT IN (SELECT path FROM finance.ap.parsed_invoices);

-- Extract from the stored parse, as often as the schema changes
SELECT path,
       ai_extract(parsed, '["invoice_id", "vendor_name", "total_amount"]',
                  MAP('instructions', 'These are vendor invoices.')) AS fields
FROM finance.ap.parsed_invoices;

When finance adds a fourth field next quarter, you pay to extract again, not to parse 150,000 pages again. The WHERE path NOT IN line keeps a nightly run from re-parsing last month's files. In a pipeline, an incremental read does the same job.

Use precision mode where the schema needs it. It is built for long documents, hundreds of line items and deeply nested or reasoning-heavy fields. For 3 header fields on an invoice, standard mode is the right tool. If a few document types need precision, run them as their own query.

Two more habits help your speed without adding cost. Send the whole dataset in one query, because the functions handle parallelism, retries and scaling themselves. And keep a sample of 100 documents to measure on before you run a month's worth.

ai_query is priced by the model you choose

ai_query sends each row to a model serving endpoint and is billed at that endpoint's rate. A Databricks-hosted pay-per-token model is billed per token, in the same way as the task-specific functions. A provisioned throughput or custom model endpoint runs on its own serving compute and is billed for that.

So the cost of an ai_query column is rows × (input tokens + output tokens) × the model's price. That last factor differs widely between small and large models. Count a sample's tokens with our token counter and compare models in the cost calculator before you pick one. Often a task-specific function such as ai_classify does the same job with a known price per 1,000 rows. Databricks recommends its own hosted models, the ones named databricks-, for batch work.

See it on your own bill

The inference lines land under 2 products, so a full view needs both. By function, last 30 days:

SELECT COALESCE(u.product_features.ai_functions.ai_function, 'ai_query and text functions') AS fn,
       SUM(u.usage_quantity) AS dbus
FROM system.billing.usage u
WHERE u.usage_date >= current_date() - INTERVAL 30 DAYS
  AND (u.billing_origin_product = 'AI_FUNCTIONS'
       OR (u.billing_origin_product = 'MODEL_SERVING'
           AND u.product_features.model_serving.offering_type = 'BATCH_INFERENCE'))
GROUP BY ALL
ORDER BY dbus DESC;

Join system.billing.list_prices on the SKU to turn DBUs into dollars, as Databricks' own example does. If the warehouse line is the larger one, look at idle time before AI: why your Databricks bill is too high covers that. If the inference line is the larger one, look first at how many pages you parse and how often you parse them again.