Polars 2 for Small and Medium Businesses: Faster Reports, Setup and Real Costs

Polars is an open source DataFrame library for loading, cleaning, joining and summarizing tables of data quickly on one computer. It fits a business whose weekly spreadsheet has become a slow copying exercise, provided someone can maintain a short script. It does not replace a shared database, permissions system or dashboard.

A DataFrame is a table with named columns and defined types. Polars has a Rust core. Its official API reference covers Python and Rust; the project also links R and Node.js bindings. This guide uses Python. The software has an MIT license, with no license fee for the open source library. Your costs are the computer, the work of writing the report and the person who fixes it when an export changes.

The useful starting point is familiar: staff download files from a point of sale, accounting, ecommerce or field service system, then rebuild the same report. Polars can repeat those preparation steps and hand back an Excel workbook. A medium business can also test whether one scheduled warehouse workload fits on a single machine. Keep a database or warehouse when many people need concurrent access, row level permissions and governance.

We read the primary sources on November 1, 2026 and ran the Python examples with Polars 2.1.0 on synthetic data. We did not deploy these systems for a customer. Every business below is an illustration, and the time estimates are our assumptions.

What changed in Polars 2?

PyPI records the 2.0.0 upload on October 6, 2026. The latest release at our check was 2.1.0, uploaded October 25. The last 1.x release was 1.44.2. Start a new trial on the pinned version used here; do not let an unattended install choose a different version tomorrow.

The 2.0 upgrade guide is substantial. These changes are especially relevant to ordinary reports:

This is only a selection from the migration list. The downloadable upgrade kit inventories the guide's changes and removed deprecations, including changes that silently alter values. SQL numeric literals, integer division and window behavior also deserve comparison tests if your scripts use SQL.

The 2.0 announcement describes out of core execution, where supported work can spill to disk. The release notes enable it by default around 80% of available RAM and set a default 64 GB disk budget. Those are engine settings. They do not mean a 64 GB dataset will fit on any laptop. The announcement describes initial support for sorting, window functions and many expressions, with out of core joins and grouping still on its roadmap. Reserve working disk and test the actual query.

2.1.0's notes add features including recursive SQL common table expressions, more SQL functions, encrypted Parquet reading and writing, and attached Iceberg catalogs. Its GeoParquet support is experimental. None is a reason to move a working weekly report before its totals have been checked.

The GPU engine remains Open Beta. It uses NVIDIA RAPIDS cuDF for lazy queries, with supported NVIDIA hardware and Linux or WSL2 requirements. Unsupported queries can fall back to the CPU. It is not the engine used in our examples, and buying a graphics card would be a poor first step for a shop importing a few CSV files.

Polars Cloud supplies managed remote execution, including distributed workloads. It is separate from the free library. The small examples here stay on one machine; the Cloud price appears below so that a future move does not look free by accident.

Five pieces of a useful reporting script

These blocks run in order. The synthetic input files use date,location,sku,amount,quantity, with rows such as 2026-09-01,North,001,$12.50,2. Each monthly export covers a different period. The product file uses sku,category, such as 001,Bread. The starter kit supplies the input contracts and more recipes.

1. Read a folder and stack its rows

import polars as pl

raw = pl.read_csv(
    "exports/*.csv",
    schema_overrides={"date": pl.String, "location": pl.String,
                      "sku": pl.String, "amount": pl.String,
                      "quantity": pl.Int64},
)
print(raw.height)

The CSV reader accepts a glob. Explicit types preserve a product code such as 001. Stacking files does not detect overlapping date ranges or duplicated transactions; add a transaction key check before using real exports.

2. Turn date and money text into usable columns

money_ok = pl.col("amount").str.contains(r"^-?\$?(?:\d+|\d{1,3}(?:,\d{3})+)\.\d{2}$")
if not raw.select(money_ok.fill_null(False).all()).item():
    raise ValueError("Expected US currency with exactly two decimal places")
sales = raw.with_columns(
    pl.col("date").str.to_date("%Y-%m-%d"),
    (pl.col("amount").str.replace_all(r"[$,]", "")
     .cast(pl.Decimal(12, 2)) * 100)
    .cast(pl.Int64).alias("revenue_cents"),
).drop("amount")

This accepts the stated US currency format, including a leading minus for refunds, and rejects malformed or missing amounts. It parses money as a decimal before storing cents as an integer. Agree a separate rule for other currencies, parenthesized negatives or prices with more than two fractional digits. A failed parse should prompt investigation. Replacing every failure with zero would make the report easier to run and harder to trust.

3. Join products and total sales by place and month

products = pl.scan_csv("products.csv", schema_overrides={"sku": pl.String})
report = (
    sales.lazy()
    .join(products, on="sku", how="left", validate="m:1")
    .with_columns(pl.col("date").dt.truncate("1mo").alias("month"))
    .group_by("location", "month", "category")
    .agg(pl.col("revenue_cents").sum(), pl.col("quantity").sum())
    .sort("location", "month", "category")
    .collect()
)

The join adds a category to each sale before the grouping. validate="m:1" rejects duplicate product keys that would multiply revenue. A left join retains unmatched sales; production checks should flag a missing category rather than quietly presenting it as a valid product group.

Eager execution runs each step immediately; lazy execution builds a plan first. Polars can then move filters and column selection earlier. Here sales is already loaded to keep the lesson readable. For a large recurring job, begin with scan_csv or scan_parquet so planning includes the file read. Calling .lazy() after reading a whole file cannot undo that earlier memory use.

4. Give people Excel and keep Parquet for the next job

from pathlib import Path
import xlsxwriter

Path("output").mkdir(exist_ok=True)
with xlsxwriter.Workbook("output/monthly.xlsx",
                         {"strings_to_formulas": False, "strings_to_urls": False}) as book:
    report.write_excel(workbook=book, worksheet="Sales")
report.write_parquet("output/monthly.parquet")

Excel writing needs XlsxWriter. This workbook keeps imported text as text instead of automatically treating it as formulas or links. Parquet stores columns with types and compression, making it a better intermediate format than repeatedly reparsing CSV. Keep CSV at the boundary when that is what your source system exports, then keep a validated Parquet copy for repeat work.

5. Let a colleague use familiar SQL

with pl.SQLContext(sales=sales, eager=True) as ctx:
    totals = ctx.execute("""
        SELECT location, SUM(revenue_cents) AS revenue_cents
        FROM sales GROUP BY location ORDER BY location
    """)
print(totals)

Polars translates SQL into its own expressions; this does not start a database server. The supported SQL subset will not accept every query copied from a warehouse. The expression API also receives new functionality first. Use whichever version your maintainer can read and test confidently.

How to install and run it

PyPI's 2.1.0 metadata requires Python 3.11 or later and lists Python 3.11 through 3.14 classifiers. Our tests used 3.12.15. The basic official install is pip install polars; for this guide, create a virtual environment and pin polars==2.1.0. With uv, use uv venv --python 3.12, then uv pip install 'polars==2.1.0' 'xlsxwriter==3.3.1'. The kit has Windows and Mac or Linux commands with explicit interpreter paths.

The installation guide lists real optional extras: calamine for the default Excel reader, xlsxwriter for writing, excel for the supported Excel engines, connectorx, adbc, sqlalchemy, database, and fsspec. They install dependencies for particular integrations. The older CPU variant is polars[rtcompat]; rt64 raises the row index limit. Neither option changes the amount of RAM in your machine.

The kit includes Task Scheduler, cron, a systemd timer and an Actions workflow. These schedule Python; Polars itself does not provide a scheduler. GitHub schedules can be delayed. A notebook is useful for discovery, but the morning report should not depend on someone remembering which cells to execute.

For cloud files, the storage guide documents reading and writing S3, Azure and Google storage. B2 offers an S3 compatible API; configure its actual endpoint and scoped credentials rather than assuming an AWS bucket URL alone is enough. Test a non-sensitive file first. We did not exercise a live cloud account in these examples.

For databases, read_database accepts a connection and read_database_uri supports ConnectorX or ADBC. ConnectorX's documented examples include PostgreSQL, MySQL, SQL Server and Redshift; ADBC needs the appropriate driver. Writing uses supported SQLAlchemy or ADBC integrations. Start with read-only access for reporting and leave operational updates in the system that owns them.

There is no universal file size to RAM multiplier here. The streaming guide explains that some operations still need in-memory execution. Measure the largest join, number of distinct groups, final result and temporary disk use. A query that reads little data can still create a huge result through a mistaken join.

Where the alternatives win

Power Query already records reusable preparation steps through a graphical editor. Try it before replacing familiar work. DuckDB is especially attractive when SQL is the team's natural language. Spark can run locally, but a cluster adds operations work that a small report rarely justifies. Our Apache data guide reaches the same starting point: solve the file problem before buying a platform.

Polars' advantages are practical: parallel work across CPU cores, lazy optimization, typed columns and Arrow interoperability. The docs describe ways to avoid unnecessary work and memory allocations. That is useful engineering, but it does not establish a universal speed or memory ratio against pandas. We ran correctness tests only; we did not benchmark business-scale data.

The disadvantages are practical too. pandas has a broader established ecosystem, and a library expecting pandas may still require a conversion. Conversions and Python callbacks can eat the expected benefit. Major versions change APIs. Polars provides no built-in staff sharing, permissions or dashboard application. Single-machine limits still apply unless you deliberately adopt a remote or distributed engine. If nobody will own a Python script, a maintained packaged tool is the better purchase.

Seven businesses with a reason to try it

These are illustrative situations. Each should start with a bounded pilot and a comparison against the current report. Setup and ongoing costs refer to the low/high cases below; none of them is a quote for a complete business system.

A bakery with eight staff and two shops

The problem might be: we spend Monday copying two tills into one workbook. A script stacks nonoverlapping point of sale exports, checks product keys and totals sales by shop and month. It runs on the manager's existing laptop; the manager reviews a workbook before ordering ingredients. Use Example A's low case, with 8 setup hours and continuing review. Waste, transfers and recipe yields need their own data before the owner can infer profit from sales.

An ecommerce brand with twelve people

The problem is orders in one export and advertising spend in another. A scheduled script joins agreed campaign and date keys, separates returns and writes a daily contribution report. Run it on the Small VPS if nobody's laptop is reliably available. Example A's high VPS case allows 24 script hours plus server setup and upkeep. On a normal morning the marketer reviews unmatched campaigns instead of rebuilding joins. It does not prove which advertisement caused a sale.

A nine person HVAC contractor

The office wants to know which jobs lose money after parts and return visits. Join job identifiers from accounting exports to labor and parts tables, keeping missing costs on an exception list. Run the first version on the office laptop, using Example A's high laptop case. The dispatcher can review questionable jobs with the owner each week. Agree how overtime and warranty visits are allocated before treating the margin as final.

A self storage facility with two staff and 180 units

The problem is checking occupancy and overdue balances in separate screens. A script joins unit status to a dated balance export and produces occupied, vacant and past-due counts. Start on an existing office laptop with Example A's low case. Staff review exceptions each morning when they choose to run it. Keep notices, payment processing and gate access in the management system; a reporting script should not make those decisions automatically.

A dental clinic with fifteen staff

The manager wants appointment utilization without sending patient details around in spreadsheets. Begin with a deliberately minimized scheduling export, aggregate appointments by date and chair, and run it on an approved managed workstation. Example A supplies a reporting labor illustration only; its budget excludes privacy assessment work. Check HIPAA applicability before storing health information on a workstation, backup service or remote runner. Daily review should use aggregate counts wherever possible, and a library choice makes no compliance claim.

A distributor with 150 employees

The problem is a nightly Excel macro that keeps someone waiting to check backorders. A script joins stock, orders and incoming deliveries, then writes an exception workbook and a typed Parquet output. Test the Medium VPS against the largest real join. Example C supplies the hosting and maintenance comparison, with 16/48 specialist setup hours. Buyers receive a reviewed list in the morning. Retain the warehouse if other departments depend on its permissions, history or concurrent queries.

A manufacturer with 250 employees

The production analyst repeatedly queries machine logs to count stoppages by shift. A Polars job can scan selected columns, apply an agreed shift calendar and produce summaries on a dedicated reporting runner. Use Example C's low/high scan frequencies to decide whether a move is worth testing. Supervisors see exceptions before the shift meeting. If the required join exceeds the Medium machine, use the Large sensitivity calculation; never promise throughput from employee count or compressed file size.

Costs: include the person who maintains it

All prices below are US dollars before tax, read November 1, 2026 unless stated otherwise. Hours, file sizes and query counts are our assumptions, shown as low and high cases. Each case is a planning scenario; none is a performance measurement or a confidence interval. Existing Excel licenses and an already managed laptop are common costs here. New hardware, major cleanup, training, specialist compliance work, incidents and excess transfer are excluded.

The May 2025 BLS national median hourly wage for Management Analysts, SOC 13-1111, is $48.97. For Data Scientists, SOC 15-2051, it is $57.80. We use the former for routine report preparation and review, and the latter as a specialist script development proxy. The occupations only set a labor rate; you do not need to hire either one.

Using the June 2026 private industry wages share of 70.0%, our loaded rates are $48.97 / 0.700 = $69.96/hour and $57.80 / 0.700 = $82.57/hour. Server work uses the shared sysadmin wage, $47.66 / 0.700 = $68.09/hour. The wage share and sysadmin observation were read October 29. These estimate employee compensation with benefits. A provider's billable rate will be higher; get a quote. An unpaid owner still spends time.

DigitalOcean's NYC3 tiers used here are Small at $24/month for 2 shared vCPU, 4 GiB RAM and 80 GiB disk; Medium at $48 for 4 shared vCPU, 8 GiB and 160 GiB; and Large, General Purpose Regular, at $252 for 8 dedicated vCPU, 32 GiB and 100 GiB. These are monthly caps without an annual commitment discount. Treat them as candidate machines to test against your own data.

Backblaze B2 starts at $6.95 per decimal TB per month, paid monthly. Our backup formula is max(0, retained GB minus the first 10 GB) x $0.00695. The free storage allowance comes from the October 29 shared research. Egress up to three times average stored data is included; additional egress is $0.01/GB. Count retained versions, and budget any chargeable requests or source provider transfer separately.

Setup = script hours x $82.57 + server setup hours x $68.09. Monthly = hosting + backup + review labor + script maintenance + server administration. Total over 36 months = setup + 36 x monthly. Savings = the alternative total minus the Polars total. Break even is the ceiling of extra setup divided by monthly savings, or never when there are no monthly savings and setup costs more. We calculate with the two decimal labor rates and unrounded intermediate amounts, then display whole dollar totals.

A. A weekly report rebuilt in Excel

Our low/high assumptions: rebuilding takes 2/4 hours weekly; the script needs 8/24 specialist setup hours; review afterward takes 0.25/0.5 analyst hours weekly; script maintenance takes 0.5/1.5 specialist hours monthly. Retained backups total 20/100 GB. The VPS option adds 4/12 server setup hours and 1/3 server administration hours monthly. Use 52 / 12 weeks per month. Backup egress stays inside the allowance.

For the low laptop case, setup is 8 x $82.57 = $660.56. Monthly is (0.25 x 52 / 12 x $69.96) + (0.5 x $82.57) + (20 minus 10) x $0.00695 = $117.1445. Its total is $660.56 + 36 x $117.1445 = $4,878, rounded.

Laptop savings over three years are $16,950/$31,735; VPS savings are $13,362/$22,700. That is staff time freed for other work. Payroll only falls if you change staffing. If nobody uses the saved time, or the export keeps breaking, the benefit will be smaller. The laptop wins this estimate; unattended availability is the reason to consider a server.

B. Polars beside a BI subscription

Power BI Pro is $14 per user per month, paid yearly. Our low/high assumptions are 3/10 users with an existing dashboard and preparation workflow. Adding Polars takes 8/24 specialist setup hours, 0.5/1.5 maintenance hours monthly, an existing laptop and 20/100 GB of backup storage. This isolates licenses and extra preparation costs; no manual time saving is assumed.

The license formula is seats x $14 x 36. Add script setup and 36 x maintenance and backups for the second row. Polars adds $2,149/$6,463. Break even from license savings is never: those licenses remain. Polars feeds a dashboard; it does not supply Power BI's sharing and access controls. Power Query may already prepare the data adequately. Measure preparation time savings separately using Example A before adding another script.

C. A medium business running repeated warehouse queries

BigQuery on-demand pricing, Iowa us-central1, is $6.25 per TiB processed after the first 1 TiB monthly. That is the on-demand model; the Standard and Enterprise capacity editions bill per slot-hour instead. Active logical storage lists $0.000031507/GiB-hour; the page's full month example is equivalent to $0.023/GiB-month, with the first 10 GiB free.

Our assumptions are one active 100 GiB logical table and 30/1,200 noncached full scans monthly, or 1/40 daily in a 30-day planning month. The project's full free allowances remain available. Query cost is max(0, 100 x scan count / 1,024 minus 1) x $6.25, giving $12/$726 monthly rounded. Storage adds (100 minus 10) x $0.023 = $2.07. Actual billing follows bytes processed and storage time; compressed Parquet size is not the logical byte count.

For the Medium VPS, assume a 50 GiB Parquet copy leaves enough disk for working files and outputs, and the real aggregation passes a trial within 8 GiB RAM and its time window. Those conditions must be measured. Streaming does not make every large join fit. Both paths allow 16/48 specialist setup hours, 0.5/1.5 monthly maintenance hours and 100 GB of B2 source backups. Polars adds 4/12 sysadmin setup hours and 1/3 monthly administration hours. Common review and source systems are excluded from both; no streaming ingestion or cross-region transfer is assumed.

Polars costs $3,943 more in the low case, so break even is never. At the high scan frequency it saves $16,318 and breaks even in month 2. If testing requires the $252 Large machine, add $204 monthly or $7,344 over three years: totals become $14,625/$25,687, with break even never/month 4. The Large tier has less included disk; these totals assume working files still fit, and extra storage would add cost. Rounded row totals can differ by a dollar from differences calculated before rounding.

The warehouse wins the modest query bill and remains preferable for concurrent users, governed access, cross-team SQL and managed operations. First reduce scans with partitions, selected columns and valid cached results. That can remove the high bill without moving anything. This model prices one batch workload. Replacing a whole warehouse is a much bigger decision.

Where Polars Cloud fits in the bill

Polars Cloud publishes an AWS service charge of $0.05 per vCPU-hour, on top of AWS compute costs. Billing begins when instances are ready and ends when they stop, so idle ready instances count too. Enterprise pricing is custom. The homepage also lists an On-Prem offer at $0.05/vCPU-hour, including 10,000 CPU hours monthly at no cost, while the FAQ still calls on-premises support a roadmap item. The FAQ appears older; confirm the current terms before selecting that route.

Our assumption of 30/480 ready-instance vCPU-hours monthly gives service fees of $1.50/$24 monthly, or $54/$864 over 36 months. That is only the service fee. Add AWS infrastructure, storage, transfer and staff time. Without a measured runtime and an AWS configuration quote, a total or break even against the VPS would be invented.

Upgrade one report at a time

Check the running environment with python -c "import polars; print(polars.__version__)". The official upgrade guidance recommends reaching the latest non-breaking release and resolving deprecation warnings before a major upgrade. For this migration that means testing 1.44.2 first, then trying 2.1.0 in a separate environment.

Freeze the original input files. Compare schemas, row counts, missing values, stable business keys and signed totals. Sort before comparing when order is not meaningful. A matching grand total can still conceal balances assigned to the wrong customers. Keep the previous environment and accepted outputs until the new report survives complete reporting cycles.

The 1.x to 2.x upgrade guide lists silent changes first, then the documented breaking APIs and removed deprecations, with search commands and test notes. The pandas and Excel migration kit has tested before and after examples. It explains why an index, null join keys and a workbook macro need thought beyond changing method names.

If you already prepare reports like these for other businesses, The $20 Dollar Agency covers turning that skill into a small service business. The script is the easy part; the client relationship and the monthly check that the numbers still reconcile are what people pay for.

Download the kits

• Small business installation and reporting kit: eleven recipes, scheduling choices, input checks, backups and the cost worksheet.
• Polars 1.x to 2.x upgrade guide: the official change inventory, tested probes, pinning and rollback.
• pandas and Excel migration kit: concept mappings, eighteen paired examples, interoperability and a workbook replacement walkthrough.

Related reading

• Apache big data: start small before buying a cluster.
• An Apache stack for small and medium businesses.
• Apache dashboards and analytics.
• Free public data repositories for small business.
• AI data flow security habits.

Fact-check notes and sources

Sources were read November 1, 2026 unless marked October 29. Observation times and the linked primary sources are below. Example tests establish behavior on synthetic inputs; they do not establish production runtime, cloud connectivity, regulatory compliance or a vendor quote.

• Identity and license, 17:55 UTC; API languages, 18:02 UTC.
• Release dates and Python requirements, 17:54 UTC; 2.1 metadata, 18:05 UTC.
• Upgrade order, 18:00 UTC; 2.0 changes, 17:55 UTC.
• 2.0 release and 2.1 release, 17:55 UTC; announcement, 17:56 UTC.
• Installation, lazy execution, streaming, SQL, 17:55 UTC.
• CSV API, join API, Parquet, 17:56 UTC.
• Excel writing, 18:08 UTC.
• Cloud files, database connectors, 17:55 UTC; GPU status, 17:56 UTC.
• Python environments, 17:56 UTC; uv environments, 17:55 UTC.
• Actions schedules, 17:55 UTC; Jupyter and marimo, 17:56 UTC.
• Power Query, Spark, 18:01 UTC; DuckDB, 17:56 UTC; pandas migration, 17:55 UTC.
• Management analyst wage, 17:55:25 UTC; data scientist wage, 17:55:19 UTC.
• Wages share, October 29 at 21:17 UTC; sysadmin wage, October 29 at 21:12 UTC.
• DigitalOcean, 17:55:51 UTC; B2 prices, 17:55:58 UTC, with free allowance from October 29 at 21:10 UTC; B2 API, 17:56 UTC.
• BigQuery architecture and row access, 18:09 UTC.
• Power BI Pro, 17:55:40 UTC; BigQuery, 17:55:30 UTC.
• Cloud prices, 17:56:34 UTC; Cloud FAQ and billing, 17:57 UTC. Prices were also checked in a US browser on November 1.
• HIPAA applicability, read November 1 in a US browser: “The HIPAA Rules apply to covered entities and business associates.”

This post is informational, not legal or financial advice. Product names identify the products discussed. No affiliation is implied.