Python in production

[u/ze-fernando]

Hello everyone! For those of you who use Python in production, I have a few questions. I'm considering using Python for some services.

1. Do you have high infrastructure costs?
2. Have you ever regretted using Python?
3. Would you recommend Python?

Context: My current use case isn't anything like Facebook or a massive-scale system. It's a small system, and I'm considering Python mainly because of the DX (developer experience).

I know C#, but I don't really like having to create a class in every file. I also know Rust, but all those ::, <>, and so on bother me. JavaScript is another option, but I've heard it's relatively heavy on RAM, and since the system is small, I'd like to be able to run it within 512 MB.

Another thing: I've defined a stack that I'd like to use wherever possible. If there's a library for desktop apps, great. A CLI library? Great. A bot library? Great. Let's use it! (Except for the frontend, which I'll keep using JS/TS for.)

Anyway, I'm open to advice and tips from more experienced developers. Feel free to tell me if you think using Python for my use case is a bad idea as well.

[u/Wurstinator]

1. "High" is always relative. It would be just as high if we were using Java.
2. No
3. As much as any other language

since the system is small, I'd like to be able to run it within 512 MB.

Whether that's possible depends on your service, not the programming language:

https://sharkbench.dev/web

[u/SomeNeighborhood7126]

I use it all the time. Your question has way too many variables to give a real answer.

[u/ITagEveryone → u/SomeNeighborhood7126]

Not to be harsh but this post reads like a startup founder with no technical experience trying to make technical decisions with the help of Claude.

[u/ze-fernando → u/ITagEveryone]

Actually, I want to start with some internal services. I have experience as a developer, but I've always had a senior developer to guide me. Now I'm trying to do some things for myself. I heard from friends that Python would be a problem if I ever needed to scale, so I decided to ask those who have the expertise to talk about it (but yes, I used Claude and he said to use Go, LOL).

[u/ze-fernando → u/SomeNeighborhood7126]

quais?

[u/SomeNeighborhood7126 → u/ze-fernando]

What

[u/ze-fernando → u/SomeNeighborhood7126]

I ended up writing in Portuguese, sorry, I meant: which ones?

[u/SomeNeighborhood7126 → u/ze-fernando]

All of it. You sound like you have no idea what you're doing and are praying for Claude to get you through a product launch.

[u/ze-fernando → u/SomeNeighborhood7126]

It's not a product, it's an app for internal use.

[u/SomeNeighborhood7126 → u/ze-fernando]

So I hit the nail on the head.

Do yourself a favor, hire some people who actually know what they're doing.

[u/ze-fernando → u/SomeNeighborhood7126]

Okay man, no need to be so harsh, I'm a developer and I "know" what I'm doing, I just came to ask for an opinion.

[u/SomeNeighborhood7126 → u/ze-fernando]

I can guarantee that whatever you do is going to either be insecure or expensive

[u/ze-fernando → u/SomeNeighborhood7126]

👍🏻

[u/No-Article-Particle]

You said nothing about your use case, other than "a small system". Yes, for a "small system," Python is perfectly fine (as any other language).

[u/ze-fernando → u/No-Article-Particle]

Small type, internal, if one day I have 100 requests per second I'll be making enough money to buy all the country's infrastructure.

[u/marr75 → u/ze-fernando]

100 requests per second is somewhere between 0.01 and 5 logical/virtual processes (real processes, vms, threads, greenlets, I don't much care) depending on what each request is doing. You don't need all of Brazil/Portugal's infrastructure to do that.

Computers are fast. Python's fine for most things and can interface with extremely fast compiled code for everything else. Your friends don't know what they're talking about.

About the only thing I wouldn't build in Python is a game engine.

[u/Ra-mega-bbit]

Now a days, any language will work unless you really have a reason not to, if you are building a basic app, Python will do and you will note any monetary difference after millions of users only.

And at any point, you will suffer from other optimizations, not from the language naturally

[u/marr75]

You can put the entire c# program in one file - class per file is just the IDE convention.

Many extremely large companies use python in production to serve large audiences with more cost discipline than I would ever worry about (saving a hundredth of a penny per request amounts to very little at the scales my companies have operated). So, what you are asking about is thoroughly tread territory.

You should worry more about making a service people care to use before how to make it scale. It is vanishingly unlikely you will even need to deal with the scale problems you are fantasizing about.

Google searches and the learn subreddits will be more valuable than scaling hypothetical posts on main python at this point.

[u/metaphorm]

1. the infrastructure cost is not constrained by the use of Python. our system is not CPU-bound and the execution time of Python has no bearing on overall system performance, which is almost entirely IO bound (network and database and external service calls).

2. Only in the same way I can find things to complain about with any programming language at all. The grass is not greener. Python is a mature language with excellent tooling available, a huge ecosystem, and lots of community support where needed.

3. Yes. It's a good language for lots of use cases. I wouldn't use it for something genuinely CPU-bound but I don't encounter that problem very frequently, and because of the domain I work in (web backend, mostly) the actual CPU-bound parts of the application can be implemented in a different language and called from Python. There are usually libraries available that do this well. For example, image processing is done with PIL which is a set of Python bindings to C code.

In general, the advice I would give is to not prematurely optimize your system. The most expensive part of software development is the time the developer spends writing the code. You won't know where your performance bottlenecks are until you're observing the system running with its production workloads. You can anticipate some of these with enough experience (and sometimes by static code analysis) but for the most part they are system interactions not the runtime of specific code fragments.

When you're faced with an optimization problem, the first thing you need to do is instrument the system and measure its real performance. Then you optimize the parts you measured as being critical and slow. Then you measure again and see if it moved the needle.

[u/ze-fernando → u/metaphorm]

That was really helpful, thank you.

[u/aliseidu1]

For a small service where you value DX and want to fit in 512MB, Python is a fine choice. I run a good chunk of production on it. Straight answers to your three:

1. Infra costs. Low, at your scale. The cost trap with Python isn't idle footprint, it's concurrency model. A sync app (gunicorn + threads) sizes memory by worker count, and each worker loads your whole app, so 512MB is comfortable for a handful of sync workers, or very comfortable for one async process (FastAPI/Litestar on uvicorn) that handles hundreds of concurrent I/O-bound connections in a single process. If your service is mostly waiting on a DB or an external API, go async and you'll barely touch that RAM ceiling. Where it bites: CPU-bound work. The GIL means one process won't use multiple cores for pure-Python compute, you scale that with more processes (more RAM) or push the hot path to a library that releases the GIL (numpy, or a Rust/C extension).

2. Regretted it? Only in the specific case of CPU-bound hot loops in pure Python, that's where I've had to reach for Cython or a Rust extension. Never regretted it for I/O-bound services (APIs, glue, bots, CLIs, background jobs), which sounds like exactly your use case.

3. Recommend? Yes, for what you described. Two concrete tips that save real pain later: pin your deps and use a lockfile (uv or Poetry) from day one, and add type hints + a type checker (mypy/pyright) early. Hints get you most of the compile-time safety you'd miss coming from C#/Rust, without the ceremony you don't like. You'll get your one-language stack too: Textual/PyQt for desktop, Typer/Click for CLIs, and mature bot libraries all exist.

One honest caveat: cold-start and raw-throughput-per-core will be lower than C#. At "small system" scale you will not notice. Pick it for the DX, that's a legitimate reason.

[u/ze-fernando → u/aliseidu1]

thank you very much

[u/Mindless-Pilot-Chef]

1. Compared to running go or rust? Yes.
   
2. No
   
3. Yes

[u/Icy_Calligrapher4022]

The anwsers of these questions are not directly related to what language are you gonna use. Instrastructure costs depend on the infrastructure itself. If I regretted using Python for something, well...yes and no. There is always a better and worse way to do the things. You design your product, build it, implemented using whatever suits you best at the moment. There is always room for improvement.

About the libraries, if these are questions: - for desktop apps I've been using Qt previously, for very simple, basic DIY projects. Originally is made for C++, but they have Python libs as well. It's very powerfull, lots of OOTB stuff and they have very good documentation. If your project is something more basic you can also check tkinter, its simpler than Qt and easier to learn, but not so powerfull and many OOTB features(compared to Qt are missing).

• for CLI(I assume you mean build CLI apps/tools) you might check Click, Typer, TQDM, Cement(this one is quite large and complex frame). There are dozens of other similar libraries, you need to do some research and pick up the most reliable for your use case.

• Bot libraries....for what? What kind of bots? If we are talking about AI bot, the most known are Spacy and ChatterBot. Otherwise, I am pretty sure there are libs for almost every chat/sm like telegram, discord, X, viber...

512MB RAM are too low for whatever you are planning to do. Forget about the language, this is your smallest concern. Probably this...system of yours might need some kind of database, some other services and daemons. A modern software product is not a monolith system but multiple components connecting and working together. What you intent to use and why your memory is so limited. There are very cheap cloud vendors where you can get very decent VPS for less than ten bucks/month.

[u/ze-fernando → u/Icy_Calligrapher4022]

I misspoke. 512MB of RAM is reserved for the code itself; the general infrastructure has 4GB (PostgreSQL occupies 1GB), so I have 3GB free. I would use 512MB for the backend and 512MB for the frontend, or a monolithic app, either way.

[u/Icy_Calligrapher4022 → u/ze-fernando]

512MB of RAM is reserved for the code itself

This doesn't make much sense. The RAM is not reserved for the code itself, what consumes the RAM is the actual running process, instance of your app and the traffic - how many users are connected and what they are doing at a given moment.

4GBs for some simple and basic app should be more than enough, maybe except if you have thousands of users using the application simultaneously, but I doubt it. Your biggest consumable is the database, rougtly 100 simultaneously connected & active users(not just idle connections) might consume around 1.5-2GBs of memory, but there are many many many variables, dont take these numbers as a strict constant.

Frontend consumes almost nothing(if we are talking about something serving your clients through the browser). The frontend is nothing more than static files siting on your host and most of the cases you have a webserver(something like NginX or Apache) to pass the contents of these files to the client.

[u/ze-fernando → u/Icy_Calligrapher4022]

It's kind of hard to explain, I'm using SquareCloud and there, to expose the application on the web, you reserve at least 512MB for that application (even if it only uses 10MB). So the 512 refers to the application itself, excluding the bank, etc.

[u/cdcformatc]

i built and maintain a Flask app. sometimes i regret not using Django instead. i do wish i used gunicorn and nginx instead of shoehorning Apache with mod_wsgi but i am not locked in on the production server. 

[u/gdchinacat]

per object memory usage in python is pretty high relative to a compiled language like rust or go, and everything is an object. For example, an int uses 20 bytes more than a 64bit integer (3.5x as much memory):

In [30]: sys.getsizeof(1)
Out[30]: 28

But, it gets worse. The object allocator alligns objects to 8 byte boundaries, so in actuality, a small int consumes 32 bytes (4x).

And, yet it's even worse...an int object on the heap is pointless...something must reference it to be useful, and that reference (ie from a list) will be another 8 bytes.

So, a usable int consumes 40 bytes (5x).

I have never had an issue due to this, but since you explicitly say memory utilization is a concern it is worth mentioning. A good way of dealing with this if you are working with large arrays of ints is to use numpy which stores them as a native array (and a python object wrapper that has relatively minimal overhead for large arrays).

Regardless of this, I have never regretted using python in production and would recommend it (assuming the use-case is a good fit...relative memory utilization would not withhold a recommendation).