I built nitro-pandas — a pandas-compatible library powered by Polars. Same syntax, up to 10x faster.

Correct_Elevator2041 · 2026-04-09T22:00:07+00:00

Totally respect that! If you’re already comfortable with Polars, there’s no reason to use nitro-pandas — just use Polars directly, it’s genuinely better. nitro-pandas is for the people who can’t or won’t make that switch, not for Polars converts like you 😄

Correct_Elevator2041 · 2026-04-09T20:34:13+00:00

Haha glad it resonated! Though with nitro-pandas you might need one less reason to forget pandas syntax, same API, just faster. You’re welcome! 😄

Correct_Elevator2041 · 2026-04-09T20:32:05+00:00

The benchmarks are on a 3GB dataset, performance scales with data size, that’s literally how vectorized engines work. On 3GB, Select+Rename alone hits 47x faster than pandas. Saying ‘5-10x isn’t supported’ based on small dataset benchmarks is like reviewing a cargo ship’s speed in a swimming pool :)

Correct_Elevator2041 · 2026-04-09T20:25:27+00:00

Really appreciate the detailed feedback! You’re right that a true 100% drop-in replacement is architecturally impossible — Polars and pandas have fundamentally different data models, and I don’t claim otherwise. reindex() is a great example of a pandas concept that doesn’t translate to Polars — it’s on the radar but honestly it might stay as a pandas fallback indefinitely. The maintainability concern is valid too. The wrapper adds complexity. The target isn’t people starting fresh, youre right that those people should just learn Polars directly. It’s more for teams with existing pandas codebases where the migration cost is a real business constraint

Correct_Elevator2041 · 2026-04-09T20:16:45+00:00

Not 100%. and I won’t claim that. The most commonly used methods (groupby, merge, loc, iloc, read_csv, filters…) are natively implemented with Polars. For anything not yet implemented, it automatically falls back to pandas so you get the same result (or a little bit slower than pandas)

Correct_Elevator2041 · 2026-04-09T20:15:50+00:00

Yes! That’s exactly the point — just do: import nitro_pandas as pd and your entire existing codebase work as is without changing another line

Correct_Elevator2041 · 2026-03-12T08:18:44+00:00

Thanks !

Correct_Elevator2041 · 2026-03-12T08:17:28+00:00

Totally understand! inplace=True isn’t supported because Polars is immutable by design — every operation returns a new DataFrame. The fix in your codebase would just be adding df = before each operation. It’s a one-liner change per call, could even be done with a simple find & replace in most cases!

Correct_Elevator2041 · 2026-03-08T10:38:16+00:00

Completely fair point — and I wouldn’t recommend anyone drop this into a critical production codebase today. It’s v0.1.5, bugs exist, and I’m transparent about that. But the use case isn’t ‘replace pandas in prod overnight’ — it’s more about giving teams a low-risk way to start benefiting from Polars performance on non-critical pipelines while the lib matures.

Correct_Elevator2041 · 2026-03-07T18:57:27+00:00

Absolutely yes — PRs and issues are very welcome! Please open an issue for each unexpected behavior you found (especially the iloc ones), it would help a lot to have specific reproducible cases. Really appreciate you testing this seriously!

Correct_Elevator2041 · 2026-03-07T18:47:10+00:00

That’s exactly why I built this! Pandas becomes muscle memory after years of use. With nitro-pandas you don’t have to fight that instinct — just change the import and you get Polars performance without unlearning anything. Let me know how it goes!

Correct_Elevator2041 · 2026-03-07T18:45:45+00:00

That’s really valuable feedback from someone who’s been through it! Would love to hear what broke specifically after you test it Monday, it would help prioritize the roadmap a lot!

Correct_Elevator2041 · 2026-03-07T18:44:19+00:00

Almost! groupby+agg and reset_index are natively implemented with Polars backend. cumsum() currently falls back to pandas but a native Polars implementation is on the roadmap. The chain itself works though!

Correct_Elevator2041 · 2026-03-07T16:56:42+00:00

Building a library from scratch and migrating a 10k lines production codebase are not the same problem. One is a weekend project, the other is a business risk. nitro-pandas exists for the second case.

Correct_Elevator2041 · 2026-03-07T16:19:02+00:00

Totally fair! Polars syntax is great. nitro-pandas is for the people who have existing pandas codebases and don’t want to rewrite everything

Correct_Elevator2041 · 2026-03-07T16:02:43+00:00

Actually it’s the opposite — nitro-pandas IS meant for end users! That’s the whole point. You write pandas syntax, Polars runs under the hood. No new API to learn. And Narwhals has its own syntax inspired by Polars, it’s not pandas-compatible out of the box.

Correct_Elevator2041

TROPHY CASE

Welcome to Reddit,