Stripe import is very slow

[silviogutierrez]

Describe the bug

I looked around, searched the issues and even googled. Surprised this hasn't come up.

Just importing the library adds 500ms to startup time. There's got to be a way to lazy load parts.

This is on a top of the line Mac with SSD.

To Reproduce

# Takes about 20 ms
time python -c "print('ok')";

# Takes bout 500ms
time python -c "print('ok'); import stripe"

Expected behavior

For serverless setups, startup time is pretty important.

Even for local development, django's runserver or uvicorn's reload are both much slower with imports like these.

Of course you can do the import locally everywhere stripe is used, but this can be problematic.

At the very least, some guidance in the docs on how to do imports and have a lazy-loaded client would help. Something like a central get_stripe_client() -> Stripe or the like. And cover thread-safety in here.

Code snippets

No response

OS

macOS

Language version

3.12.1

Library version

11.3.0

API version

2020-08-27

Additional context

No response

[devraj]

Out of curiosity what serverless platform are you deploying to? This would only be an issue on cold starts, is that correct?

[silviogutierrez]

For production, yes, it's mostly an issue with cold starts. If you use python's importtime you can see Stripe takes up a big, big chunk. See more here: https://adamj.eu/tech/2023/03/02/django-profile-and-improve-import-time/

Cold start platforms: Google Cloud Run in my case.

But it also has local dev implications. Django and FastAPI rely on an autoreloading server. Unlike frontend tools like vite, there's no concept of hot module reloading. So this library — with no usage, just importing — is responsible for a 500ms lag in restarts.

Imagine a few other libraries like this (Google storage does the same thing), and it starts to add up.

[prathmesh-stripe]

Thanks for reporting this. We will be looking into SDK optimizations in the new year.

[bufke]

I noticed that that ram usage has crept up to very high levels with just import stripe

• 4.2.0 - 11mb
• 7.14.0 - 28mb
• 11.5.0 - 57mb

I tested with Docker python:3.13 image. I ran pip install stripe==version. Run python. Measure process memory. Run import stripe. Measure again and take the difference.

I discovered this by noticing a major memory usage regression in my web application, which is attributed to upgrading stripe. This is likely the same issue, though I'd argue the memory usage is just as bad or worse as the slow start time. For comparison, my entire Celery process is only 80mb, this increase was enough to halt release and investigate for me.

[bufke]

I took a peek with memray. I see that it imports both aiohttp and requests, lovely. Those were installed in my testing environment. _test_helpers_service looks questionable for importing. https://gitlab.com/-/snippets/4802529

[stianjensen]

Some of the import time regression could be inside requests itself, depending on which version of requests you're getting with the different versions of stripe you tested:
psf/requests#6790

[rsinger86]

I had to increase the capacity of my Fargate ECS service after adding this SDK to my project. Some optimizations would be much appreciated.

[chris-mui]

Can confirm the memory usage has been an issue for us as well. We ended up refactoring out the stripe-python sdk. Claude makes short work out of building your own stripe.construct_event() method, dropped 50mb per worker from our memory use.

[silviogutierrez]

@chris-mui could you elaborate on this? Do you mean still installing the library and going more low level?

Or just actual API requests directly?

[chris-mui]

Completely removed stripe sdk. Copy pasted api spec into claude to build out pydantic models for handling the requests. Construct_event() which handles webhook signature verification built in a similar fashion (didn't need any context to build this one though).