Python Data Libraries Cheat Sheet 2026 — Quick Reference

Every data scientist working in Python juggles at least three libraries in a single afternoon: Pandas for the familiar API, Polars when a job is too slow to wait for, and DuckDB when the fastest path from a pile of Parquet files to an answer is just writing SQL. This cheat sheet lines up the syntax for all three side by side, plus NumPy and the plotting stack, so you can translate between them without losing your place. Below the tables, we explain why the three libraries behave so differently under the hood and when switching actually pays off.

For deeper context on each library, see Polars vs Pandas, DuckDB vs Pandas, and Best Data Science Tools 2026.

---

Why three libraries, not one

Pandas has been the default Python data library since it was open-sourced by Wes McKinney in 2009, and it remains the library most tutorials, Stack Overflow answers, and coworkers assume you're using. It's built on NumPy arrays, runs on a single CPU core by default, and evaluates every line the instant you write it (this is called "eager execution" — the opposite of waiting and optimizing a whole chain of steps before running any of it).

That single-core, eager design is exactly what makes Pandas simple to reason about and exactly what makes it slow on anything larger than a few hundred megabytes. Polars, written in Rust and first released in 2020, was built specifically to fix that: it uses all available CPU cores by default and offers a "lazy" mode that inspects your entire chain of .filter(), .group_by(), and .select() calls before running any of them, so it can skip work that never affects the final answer. DuckDB takes a third approach entirely — instead of a DataFrame API, it gives you a real SQL engine that runs inside your Python process (no server, no separate database to manage) and is purpose-built for the kind of scan-heavy, aggregate-heavy queries that come up constantly in analytics.

On a 10-million-row group-by benchmark, Polars completed the operation in roughly 0.45 seconds, and independent 2026 testing found Polars processing a 12 GB file in under 2 GB of RAM using lazy streaming execution, while the equivalent Pandas operation held the entire dataset in memory at once ([Pandas vs. Polars 2026 Benchmark & Survival Guide](https://medium.com/@abayomiajiboye46111/pandas-vs-polars-the-2026-benchmark-survival-guide-e352c3ca4e5f)).

None of the three is "wrong" to use. A data scientist cleaning a 50,000-row CSV for a one-off analysis gains nothing from Polars' parallelism. A data engineer joining 40 million rows of clickstream data against a dimension table every night gains everything from it. The rest of this cheat sheet assumes you already know roughly what you're doing and just need the syntax translated — the analysis sections after the tables explain the why behind each choice.

---

Reading files

Operation	Pandas	Polars	DuckDB
CSV	pd.read_csv('f.csv')	pl.read_csv('f.csv')	duckdb.sql("FROM 'f.csv'").df()
Parquet	pd.read_parquet('f.pq')	pl.read_parquet('f.pq')	duckdb.sql("FROM 'f.parquet'").df()
JSON	pd.read_json('f.json')	pl.read_json('f.json')	duckdb.sql("FROM 'f.json'").df()
Excel	pd.read_excel('f.xlsx')	pl.read_excel('f.xlsx')	Via pandas
SQL	pd.read_sql(q, conn)	pl.read_database(q, conn)	Native
URL	pd.read_csv(url)	pl.read_csv(url)	duckdb.sql("FROM read_csv('url')")

Table 1: File-reading syntax across Pandas, Polars, and DuckDB. DuckDB can query files directly without a preceding "load" step — that's a deliberate design choice, not a shortcut.

Why does DuckDB skip the "load" step entirely?

DuckDB is a columnar-vectorized query engine, which means it reads data in batches of column values rather than row by row, and it can push filters down into the file scan itself. Querying 'data/*.parquet' directly lets DuckDB read only the columns and row groups a query actually needs, instead of materializing the whole file into memory first (DuckDB: An Embeddable Analytical Database, SIGMOD 2019).

---

Inspection

# Pandas
df.head(5)              # First 5 rows
df.tail(5)               # Last 5
df.shape                 # (rows, cols)
df.info()                # Types + non-null counts
df.describe()             # Statistics
df.dtypes                # Column types
df.columns                # Column names
df.isnull().sum()         # Missing values per column

# Polars
df.head(5)
df.tail(5)
df.shape
df.schema                 # Column types
df.describe()
df.null_count()            # Missing per column

# DuckDB
df.show()
df.shape
df.describe()

A quick habit worth building regardless of library: run .dtypes or .schema before you run anything else. Mismatched types (a column of numbers stored as text, a date stored as a string) cause more silent bugs in real pipelines than any other single issue, and catching it in the inspection step costs seconds instead of an afternoon of debugging.

---

Selecting data

Pandas

df['column']                       # Single column → Series
df[['col1', 'col2']]               # Multiple columns → DataFrame
df.iloc[0]                         # First row by position
df.iloc[0:5]                       # Rows 0-4
df.iloc[:, 0:3]                     # First 3 columns
df.loc[df['x'] > 0]                # Filter by condition
df.loc[df['x'] > 0, 'y']            # Conditional + column
df.query("x > 0 and y < 10")        # SQL-like filter

Polars

df['column']                                       # Column → Series
df.select(['col1', 'col2'])                          # Multiple columns
df[0]                                                # First row
df[0:5]                                              # First 5 rows
df.filter(pl.col('x') > 0)                            # Filter
df.filter((pl.col('x') > 0) & (pl.col('y') < 10))     # Multi-condition

DuckDB

duckdb.sql("SELECT column FROM df")
duckdb.sql("SELECT col1, col2 FROM df")
duckdb.sql("SELECT * FROM df WHERE x > 0")
duckdb.sql("SELECT * FROM df WHERE x > 0 AND y < 10")

Think of .loc/.iloc in Pandas like a librarian who can find a book either by its exact shelf position (iloc, position-based) or by its catalog label (loc, label-based). Polars drops that dual system entirely in favor of one consistent verb, .filter(), which is part of why Polars code reads more predictably once you're used to it — there's only one way to ask for a subset of rows, not two.

---

Adding columns

# Pandas
df['new_col'] = df['x'] * 2
df['total'] = df['quantity'] * df['price']
df.assign(new_col=df['x']*2)        # Returns new DataFrame

# Polars
df = df.with_columns(
    new_col = pl.col('x') * 2,
    total = pl.col('quantity') * pl.col('price'),
)

# DuckDB
duckdb.sql("""
    SELECT *, x * 2 AS new_col, quantity * price AS total
    FROM df
""")

Why does Polars require with_columns instead of direct assignment?

Pandas lets you mutate a DataFrame in place with df['new_col'] = ..., which is convenient but makes it easy to accidentally modify a DataFrame that another part of your code still expects unchanged. Polars' with_columns() always returns a new DataFrame (or lazily queues the operation), which trades a little typing for a guarantee that your original data is never silently altered mid-pipeline.

---

Filtering

# Pandas
df[df['x'] > 0]
df[(df['x'] > 0) & (df['y'] < 10)]
df[df['name'].isin(['Alice', 'Bob'])]
df[df['email'].str.contains('@gmail')]
df[~df['x'].isnull()]                # Not null

# Polars
df.filter(pl.col('x') > 0)
df.filter((pl.col('x') > 0) & (pl.col('y') < 10))
df.filter(pl.col('name').is_in(['Alice', 'Bob']))
df.filter(pl.col('email').str.contains('@gmail'))
df.filter(pl.col('x').is_not_null())

# DuckDB — just SQL
duckdb.sql("SELECT * FROM df WHERE x > 0 AND y < 10")

One habit that separates fast Pandas code from slow Pandas code: chained boolean masks like df[(df['x'] > 0) & (df['y'] < 10)] create a new intermediate array for every condition. On small data that's invisible. On a 10-million-row DataFrame with five stacked conditions, it adds up to real seconds. .query() and Polars' .filter() both avoid building those intermediate arrays because they evaluate expressions as a single compiled operation instead of Python-level boolean masking.

---

Grouping and aggregation

# Pandas
df.groupby('category').size()
df.groupby('category')['amount'].sum()
df.groupby('category').agg({'amount': 'sum', 'count': 'mean'})
df.groupby(['cat1', 'cat2']).agg(
    total_amount=('amount', 'sum'),
    avg_amount=('amount', 'mean'),
    count=('id', 'count')
).reset_index()

# Polars
df.group_by('category').agg(pl.col('amount').sum())
df.group_by('category').agg([
    pl.col('amount').sum().alias('total'),
    pl.col('amount').mean().alias('avg'),
    pl.col('id').count().alias('count'),
])

# DuckDB
duckdb.sql("""
    SELECT category, SUM(amount) as total, AVG(amount) as avg, COUNT(id) as count
    FROM df
    GROUP BY category
""")

Group-by is where the performance gap between the three libraries is most visible in real-world testing. Independent 2026 benchmarking on H2O.ai-style group-by workloads at the 10-million-row scale found Polars roughly an order of magnitude faster than Pandas on the same hardware (Polars vs Pandas 2026: 15x Speed Gap, Tested). The reason comes down to threading: Pandas' groupby() runs on a single core no matter how many cores your machine has, while Polars and DuckDB both split the aggregation across all available cores automatically.

---

Sorting

# Pandas
df.sort_values('amount')
df.sort_values('amount', ascending=False)
df.sort_values(['cat', 'amount'], ascending=[True, False])

# Polars
df.sort('amount')
df.sort('amount', descending=True)
df.sort(['cat', 'amount'], descending=[False, True])

# DuckDB
duckdb.sql("SELECT * FROM df ORDER BY amount DESC")

---

Joining

# Pandas
df1.merge(df2, on='key', how='inner')       # Default
df1.merge(df2, on='key', how='left')
df1.merge(df2, left_on='id1', right_on='id2')

# Polars
df1.join(df2, on='key', how='inner')
df1.join(df2, on='key', how='left')

# DuckDB — just SQL
duckdb.sql("""
    SELECT * FROM df1
    LEFT JOIN df2 ON df1.key = df2.key
""")

Joins are the second place where the libraries diverge sharply. Independent 2026 benchmark testing measured Polars completing large joins roughly 9 times faster than Pandas on multi-gigabyte tables (Polars vs Pandas 2026: Benchmarks on Joins, Strings, I/O). If your pipeline's slowest step is a merge() on a table with millions of rows, that's usually the first place to try Polars or DuckDB before you try anything more drastic like moving to a cluster.

---

Date/time

# Pandas
df['date'] = pd.to_datetime(df['date'])
df['year'] = df['date'].dt.year
df['month'] = df['date'].dt.month
df['day_of_week'] = df['date'].dt.dayofweek
df[df['date'] >= '2024-01-01']

# Polars
df = df.with_columns(pl.col('date').str.to_datetime())
df = df.with_columns(
    year = pl.col('date').dt.year(),
    month = pl.col('date').dt.month(),
    weekday = pl.col('date').dt.weekday(),
)
df.filter(pl.col('date') >= pl.lit('2024-01-01').str.to_date())

---

String operations

# Pandas
df['email'].str.lower()
df['email'].str.strip()
df['email'].str.contains('@gmail')
df['name'].str.replace('Mr.', 'Mister')
df['name'].str.split(' ', expand=True)[0]     # First name

# Polars
df = df.with_columns(
    pl.col('email').str.to_lowercase(),
    pl.col('email').str.strip_chars(),
    contains_gmail = pl.col('email').str.contains('@gmail'),
)

String work is the one category where Pandas can actually hold its own or even win, despite losing everywhere else. Testing in 2026 found Pandas remained faster than Polars for heavy string-manipulation workloads in some cases, a reminder that "faster" isn't a single universal property of a library — it depends on the operation (Polars vs Pandas 2026 Benchmark & Survival Guide). If your pipeline is dominated by regex cleanup on a text column rather than joins or aggregations, don't assume switching libraries will automatically speed things up — profile first.

---

Handling missing data

# Pandas
df.dropna()                            # Drop any rows with NaN
df.dropna(subset=['col'])               # Drop only if col is NaN
df.fillna(0)                            # Fill with 0
df.fillna(df.mean())                    # Fill with mean
df['col'].fillna(method='ffill')         # Forward fill

# Polars
df.drop_nulls()
df.drop_nulls(subset=['col'])
df.fill_null(0)
df.with_columns(pl.col('x').fill_null(pl.col('x').mean()))
df.with_columns(pl.col('x').forward_fill())

See: How to Handle Missing Data for a deeper look at when deletion, mean imputation, and forward-fill each make sense — the syntax above is the "how," that article covers the "which one."

---

Window functions

# Pandas
df['rank'] = df['amount'].rank(ascending=False)
df['rolling_avg'] = df['amount'].rolling(7).mean()
df['cumsum'] = df['amount'].cumsum()
df['lag_1'] = df['amount'].shift(1)

# Polars
df = df.with_columns(
    rank = pl.col('amount').rank(descending=True),
    rolling_avg = pl.col('amount').rolling_mean(window_size=7),
    cumsum = pl.col('amount').cum_sum(),
    lag_1 = pl.col('amount').shift(1),
)

# DuckDB
duckdb.sql("""
    SELECT *,
        ROW_NUMBER() OVER (ORDER BY amount DESC) as rank,
        AVG(amount) OVER (ORDER BY date ROWS BETWEEN 6 PRECEDING AND CURRENT ROW) as rolling_avg,
        SUM(amount) OVER (ORDER BY date) as cumsum,
        LAG(amount, 1) OVER (ORDER BY date) as lag_1
    FROM df
""")

A window function answers a question a plain group-by can't: "what's this row's value relative to its neighbors?" instead of "what's the total for this group?" A rolling 7-day average is like checking your weight on a scale every day but reporting the average of the last week instead of the single daily number — it smooths out noise without throwing away the daily granularity the way a monthly average would.

---

Pivot tables

# Pandas
df.pivot_table(index='date', columns='category', values='amount', aggfunc='sum')

# Polars
df.pivot(values='amount', index='date', columns='category', aggregate_function='sum')

---

Common statistics

# Pandas (and similar for Polars)
df['col'].mean()
df['col'].median()
df['col'].std()
df['col'].quantile([0.25, 0.5, 0.75])
df.corr()                                # Correlation matrix
df['col'].value_counts()
df['col'].value_counts(normalize=True)     # As fractions

---

Plotting

# Matplotlib (with Pandas)
import matplotlib.pyplot as plt

df['amount'].hist(bins=30)
plt.show()

df.groupby('date')['amount'].sum().plot(kind='line')
df.groupby('category')['amount'].mean().plot(kind='barh')

# Seaborn (nicer defaults)
import seaborn as sns
sns.boxplot(data=df, x='category', y='amount')
sns.scatterplot(data=df, x='x', y='y', hue='category')

# Plotly (interactive)
import plotly.express as px
fig = px.scatter(df, x='x', y='y', color='category')
fig.show()

Matplotlib, Seaborn, and Plotly aren't competing solutions to the same problem, they're layered on top of each other. Seaborn is a set of statistical chart defaults built on Matplotlib's drawing engine, so a sns.boxplot() call is quietly doing Matplotlib work underneath with better default colors and spacing. Plotly is the odd one out: it renders to interactive HTML/JavaScript rather than a static image, which is why it's the right choice for a dashboard someone will hover over and the wrong choice for a chart you're pasting into a PDF report. See Data Visualization Tools 2026 for a fuller comparison including Tableau and Power BI.

---

NumPy essentials

import numpy as np

# Create arrays
arr = np.array([1, 2, 3, 4, 5])
zeros = np.zeros(10)
ones = np.ones((3, 3))
range_arr = np.arange(0, 10)
linspace = np.linspace(0, 1, 100)
random_arr = np.random.randn(100)          # Standard normal
random_int = np.random.randint(0, 10, 100)

# Operations
arr.mean()
arr.std()
arr.sum()
arr.min(), arr.max()
np.median(arr)
np.percentile(arr, [25, 50, 75])

# Vectorized operations
arr * 2
arr + arr
np.log(arr)
np.exp(arr)
arr ** 2

# Boolean operations
arr > 3
arr[arr > 3]
np.where(arr > 3, 'high', 'low')

# Matrix ops
A = np.random.randn(100, 5)
A.T                            # Transpose
A @ A.T                        # Matrix multiply
np.linalg.inv(A.T @ A)          # Matrix inverse

Pandas is built directly on top of NumPy — every numeric column in a Pandas DataFrame is, underneath, a NumPy array. That's worth understanding because it explains a common gotcha: arr * 2 above runs the multiplication once across the entire array in optimized C code (this is what "vectorized" means), whereas a Python for loop doing the same multiplication one element at a time runs the same operation through the much slower Python interpreter on every single step. Vectorization is the single biggest lever a Pandas or NumPy user has for performance without switching libraries at all — before reaching for Polars, check whether you're accidentally looping in Python where a vectorized call would do.

---

Quick ML with scikit-learn

from sklearn.model_selection import train_test_split, cross_val_score
from sklearn.preprocessing import StandardScaler
from sklearn.ensemble import RandomForestClassifier
from sklearn.metrics import classification_report

# Split
X_train, X_test, y_train, y_test = train_test_split(
    X, y, test_size=0.2, random_state=42, stratify=y
)

# Scale
scaler = StandardScaler()
X_train_scaled = scaler.fit_transform(X_train)
X_test_scaled = scaler.transform(X_test)

# Model
model = RandomForestClassifier(n_estimators=200, random_state=42)
model.fit(X_train_scaled, y_train)

# Evaluate
print(model.score(X_test_scaled, y_test))
print(classification_report(y_test, model.predict(X_test_scaled)))

# Cross-validation
scores = cross_val_score(model, X_train_scaled, y_train, cv=5)
print(f"CV: {scores.mean():.3f} ± {scores.std():.3f}")

stratify=y in the split call is easy to skip and expensive to skip wrong. Without it, a random 80/20 split on an imbalanced dataset — say, fraud detection where fraud is 2% of rows — can leave your test set with almost no positive examples, making your evaluation metrics meaningless even though the code runs without error.

---

Saving results

# Pandas
df.to_csv('out.csv', index=False)
df.to_parquet('out.parquet')
df.to_excel('out.xlsx', index=False)
df.to_json('out.json', orient='records')

# Polars
df.write_csv('out.csv')
df.write_parquet('out.parquet')
df.write_json('out.json')

# Pickle (preserves types perfectly, Python-only)
df.to_pickle('out.pkl')

CSV is the most portable format and the worst format for anything else — it stores every value as text, so a re-read has to re-guess types, and it has no compression. Parquet stores data by column (matching how DuckDB and Polars read it) and compresses well, which is why it's the default choice for anything you'll analyze again rather than just hand off to someone in Excel.

---

Performance tips

Pandas

# Use categorical for low-cardinality strings
df['country'] = df['country'].astype('category')

# Use efficient dtypes
df['age'] = df['age'].astype('int8')          # If 0-127
df['large_int'] = df['large_int'].astype('int32')

# Avoid loops — vectorize
# Bad
for i in range(len(df)):
    df.at[i, 'new'] = df.at[i, 'x'] * 2

# Good
df['new'] = df['x'] * 2

Polars

# Use lazy evaluation for complex queries
lf = pl.scan_csv('large.csv')          # Lazy
result = (
    lf.filter(pl.col('amount') > 100)
      .group_by('category')
      .agg(pl.col('amount').sum())
      .collect()                        # Execute optimized plan
)

DuckDB

# Query Parquet directly — no loading
duckdb.sql("SELECT category, SUM(amount) FROM 'data.parquet' GROUP BY category")

# Multiple files at once
duckdb.sql("SELECT * FROM 'data/*.parquet' WHERE date > '2024-01-01'")

Why does pl.scan_csv matter more than pl.read_csv?

read_csv loads the entire file into memory immediately, the same way Pandas does. scan_csv instead builds a lazy query plan and only executes it (reading only what's needed) when you call .collect(). This is how Polars processes files far larger than available RAM: independent 2026 testing measured a 12 GB CSV processed successfully using under 2 GB of RAM through this lazy streaming path (Polars vs Pandas in 2026: Performance Benchmarks). If you only remember one Polars habit, make it "scan, don't read, for anything bigger than your laptop's spare RAM."

---

Where each library actually wins

The tables above show how to do the same thing three ways. This section is about which library to reach for first, because the syntax translation only matters once you've picked one.

Pandas wins on:

• Compatibility. Nearly every tutorial, Stack Overflow answer, and scikit-learn example assumes a Pandas DataFrame. If you're new to data work, learn Pandas first, not because it's technically superior but because the ecosystem is built around it.
• Small-to-medium data. Independent 2026 testing found datasets under roughly 1 GB show negligible performance difference between Pandas and Polars, so switching buys you nothing on a dataset that fits comfortably in memory (Polars & DuckDB vs Pandas: Python Guide 2026).
• Heavy text and string cleaning, where its performance is sometimes competitive with or better than Polars.

Polars wins on:

• Anything CPU-bound and multi-gigabyte: joins, group-bys, sorts. Multi-core by default means you get a speedup proportional to your CPU core count without writing any parallel code yourself.
• Memory-constrained environments. The Arrow-based columnar layout Polars uses is tightly packed compared to Pandas' NumPy-block-plus-Python-object layout, and lazy execution lets you process files larger than RAM.
• New pipelines being built from scratch, where you're not fighting existing Pandas-only dependencies.

DuckDB wins on:

• Anyone who thinks in SQL first. If your instinct is SELECT ... GROUP BY, DuckDB lets you write that directly against a DataFrame, a Parquet file, or a folder of Parquet files without an ETL step.
• Querying files larger than memory without loading them at all — DuckDB's vectorized execution engine scans only the columns and row groups a query touches.
• Interop. DuckDB can query a Pandas DataFrame, a Polars DataFrame, and raw files in the same statement, which makes it a useful glue layer rather than a full replacement for either.

---

What people get wrong about switching

The most common mistake is treating "Polars is faster" as a blanket truth and rewriting an entire codebase before checking whether the current bottleneck is actually in the DataFrame library at all. If your pipeline spends 90% of its time waiting on a network API or writing to a slow disk, swapping Pandas for Polars won't move the needle — profile first, then optimize the actual bottleneck.

The second mistake is assuming migration is a find-and-replace exercise. Polars' API deliberately diverges from Pandas in places — no implicit index, .filter() instead of boolean masking, with_columns() instead of direct column assignment — because those choices were made for consistency and performance, not to make migration easy. Budget real time for the switch, not an afternoon.

The third mistake is picking DuckDB or Polars because they seem more "cutting edge" for a job where a straightforward Pandas script already runs in four seconds. If nobody is waiting on that four seconds, there's no problem to solve. Match the tool to the actual constraint, not to which library trended on a coding forum this month.

---

Frequently asked questions

Q: Can I use Pandas, Polars, and DuckDB in the same script? Yes, and it's common in practice. A typical pattern is querying a large Parquet dataset with DuckDB to pull the relevant slice, converting the result to a Pandas or Polars DataFrame with .df() or .pl(), and then using scikit-learn or a plotting library on the smaller result. DuckDB's Python integration is explicitly designed to interoperate with both.

Q: Does Polars replace Pandas entirely? Not for most teams yet. Pandas remains the default in tutorials, textbooks, and much of the scikit-learn ecosystem, and Polars still has gaps in some plotting-library and legacy-tool integrations. Polars is best understood as the tool you reach for when Pandas is measurably too slow, not as a universal replacement.

Q: Is DuckDB a real database I need to install and manage? No. DuckDB is in-process, meaning it runs as a library inside your Python program the same way Pandas does — there's no separate server, no connection string, and no admin overhead. You import duckdb and start querying.

Q: Why is my Pandas groupby() so much slower than the same operation in Polars? Pandas' groupby() runs on a single CPU core regardless of how many cores your machine has. Polars and DuckDB both parallelize aggregations across all available cores automatically, which is the main reason group-by and join benchmarks favor them so heavily at scale.

Q: What's the difference between .loc and .iloc in Pandas? .iloc selects by integer position (the 0th row, the 3rd column), while .loc selects by label (a named index value or column name) and also accepts boolean conditions. Mixing them up is one of the most common Pandas bugs for beginners.

Q: Should I convert my whole pipeline to Polars if I'm hitting memory errors? Not necessarily as a first step. Try Polars' lazy scan_csv/scan_parquet mode first, since the memory savings come primarily from lazy, streaming execution rather than from Polars being written in Rust. If lazy execution alone solves the memory error, you may not need to rewrite the rest of your pipeline.

Q: Is NumPy still relevant if I mostly use Pandas or Polars? Yes. Every numeric Pandas column is backed by a NumPy array, and many machine learning libraries (scikit-learn included) expect NumPy arrays as input at some point in the pipeline. Understanding vectorization at the NumPy level explains why "avoid Python for-loops" is the single most repeated performance tip across every library in this cheat sheet.

Q: When should I reach for Plotly instead of Matplotlib or Seaborn? Reach for Plotly when the chart needs to be interactive, such as a dashboard where someone hovers over points for details or zooms into a time series. Reach for Matplotlib or Seaborn when you need a static image for a report, paper, or presentation slide, since they render faster and embed more predictably in PDFs.

Q: Does switching to Polars or DuckDB always mean giving up Pandas syntax? No. Both libraries offer easy conversion to and from Pandas (.to_pandas() in Polars, .df() in DuckDB), so a common pattern is doing the heavy lifting (large joins, aggregations) in Polars or DuckDB and then converting the smaller, already-reduced result back to Pandas for compatibility with plotting or modeling code that expects it.

---

Related articles

• Best Data Science Tools 2026
• Pandas vs Polars
• DuckDB vs Pandas
• Data Cleaning: 80% of Data Scientist's Job
• Data Visualization Tools 2026

---

The takeaway

Bookmark this cheat sheet, but don't let it substitute for understanding the underlying trade-off: Pandas trades speed for compatibility and a shallower learning curve, Polars trades a bit of API familiarity for multi-core speed and lower memory use, and DuckDB trades a DataFrame API entirely for SQL and best-in-class file scanning. Knowing all three well is more useful in 2026 than deep fluency in just one, because the right choice depends on the size of your data and the shape of your problem, not on which library is fashionable this year. Reach for Pandas by default, reach for Polars when a job is measurably too slow or too large for memory, and reach for DuckDB when the question you're asking is more naturally a SELECT statement than a chain of DataFrame methods.

Last verified: July 2026.