People love comparing Python API frameworks with tiny JSON responses, no real database behaviour, no authentication, no nested objects, no resource limits, and no production-shaped workload.
It produces nice charts.
It also tells you very little about whether a system will survive real users, messy data, slow queries, large responses, auth flows, external APIs, memory pressure, or the one customer who somehow manages to click the same button 47 times.
This week’s edition is about what Python performance actually means in production, how candidates can prove they understand it, and how hiring managers can test for it.
The signal this week
A current Python API framework benchmark got attention because it tried to measure more realistic workloads instead of raw “hello world” responses.
The interesting part was not which framework won.
The interesting part was the benchmark shape:
frameworks running inside Docker containers
fixed CPU and memory limits
PostgreSQL included
multiple endpoints
JSON payload sizes
simple database reads
paginated data with nested relations
article detail pages
JWT / cookie authentication flows
median results across multiple container starts
That is much closer to the real work backend engineers do.
It also makes the point hiring teams often miss:
Framework choice matters, but system design matters more.
FastAPI, Django REST Framework, Django Ninja, Litestar, Bolt, Flask, or anything else can be the wrong choice if the engineer does not understand the workload.
The performance question is not:
“Which framework is fastest?”
The better question is:
“What exactly are we asking the system to do?”
Why “hello world” benchmarks mislead teams
A simple benchmark might test how quickly a framework can return:
{"message": "hello"}
Useful? Barely.
Real applications deal with:
authentication
authorization
database connection pooling
ORM overhead
serialization and validation
pagination
nested relations
external APIs
caching
large payloads
background jobs
rate limiting
error paths
logs and traces
cold starts
memory pressure
deployment constraints
A framework can look incredible in a synthetic test and behave very differently once the app is doing actual work.
This is why experienced Python engineers care less about headline requests per second and more about:
p95 latency
p99 latency
memory per worker
database wait time
connection pool saturation
slow query behaviour
serialization cost
auth overhead
tail latency under load
failure modes
In other words, the boring metrics.
Naturally, the boring metrics are the ones that matter. Software, being spiteful, works like that.
The big lesson: performance is workload-specific
There is no universal answer to:
“Is FastAPI faster than Django?”
Or:
“Should we use Litestar, Django Ninja, or DRF?”
The correct answer is usually:
“What are we building?”
A financial modelling tool is not the same workload as a social feed.
A document-processing platform is not the same workload as a CRUD dashboard.
A high-volume trading analytics system is not the same workload as an internal admin app.
A system that returns small JSON responses is not the same as one that streams files, calculates scenarios, talks to spreadsheets, or writes complex ledger data.
If you are building serious financial modelling software, performance might depend more on:
calculation engine design
caching
spreadsheet interaction patterns
model recalculation strategy
serialization
data shape
async job handling
memory usage
API boundaries
how much work happens inside the request path
The framework is part of the answer.
It is not the whole answer.
What Python engineers should learn from this
If you are a Python developer, the takeaway is simple:
Do not talk about performance like a framework fan account.
Talk about the workload.
A weak answer:
“FastAPI is fast.”
A strong answer:
“I’d benchmark the specific workload: auth, DB reads and writes, payload size, serialization, p95 latency, memory per worker, connection pool waits, and what happens when downstream services slow down.”
That sounds like someone who has been near production.
Poor soul.
A practical performance checklist
If you are building or reviewing a Python backend, ask these questions.
Request path
What work happens before the response is returned?
Is any heavy processing sitting inside the request lifecycle?
Are external calls timed out and retried safely?
Are we returning large payloads unnecessarily?
Can the user trigger duplicate work?
Database
Are queries indexed properly?
Are we creating N+1 query problems?
Are connection pools sized correctly?
Are transactions scoped carefully?
Are slow queries visible?
Are we measuring DB wait time?
Serialization and validation
Are response models expensive to build?
Are we serializing more data than the client needs?
Is validation happening repeatedly?
Are nested objects creating avoidable cost?
Are we using the right serializer for the workload?
Deployment
How many workers are running?
What is memory per worker?
Are CPU and memory limits realistic?
Does the app scale horizontally?
Are cold starts acceptable?
Are logs and metrics consistent across replicas?
Observability
p50, p95, p99 latency
request volume
error rate
memory usage
CPU usage
database pool waits
slow queries
external API latency
queue depth
retry count
failed background jobs
That is what performance work actually looks like.
It is less glamorous than arguing about frameworks, but it has the advantage of being useful.
How to prove this as a candidate
If you are applying for Python backend, product engineering, AI engineering, or fintech roles, build a project that proves you understand production-shaped performance.
A strong project could be:
Financial scenario API
Build a small FastAPI or Django backend that lets users create financial models, run scenario calculations, and return results.
Include:
Postgres
authentication
user-owned models
nested data
scenario calculations
background job for heavier runs
caching for repeated calculations
structured logging
metrics
Docker
tests
load test with realistic payloads
Then add a README section called:
“How I measured performance”
Cover:
what endpoints you benchmarked
what payload sizes you used
whether auth was included
whether DB access was included
p95 and p99 latency
memory usage
bottlenecks found
what you changed
what you would test next
That is far more impressive than saying “I know FastAPI.”
What hiring managers should test
If you are hiring Python engineers, especially senior, lead, or staff-level, performance questions should be workload-based.
Do not ask:
“Which Python framework is fastest?”
Ask:
“You have a Python API endpoint that authenticates the user, reads nested data from Postgres, performs a calculation, writes an audit log, and returns a large response. p95 latency has jumped from 300ms to 2 seconds. How do you investigate?”
A strong candidate should mention:
checking recent deploys
looking at p95 and p99, not just averages
profiling the endpoint
checking database query plans
looking for N+1 queries
inspecting connection pool waits
measuring serialization cost
checking payload size
checking external dependencies
reviewing worker CPU and memory
adding or reviewing traces
reproducing the workload locally or in staging
narrowing before rewriting
A weak candidate will immediately blame Python, the framework, or “the cloud.”
The cloud is guilty of many things, but it should still receive a fair trial.
A better interview exercise
Give candidates a small API with:
authentication
one DB query that causes N+1 behaviour
one overly large response model
one slow calculation inside the request path
weak logging
no timeout on an external call
Ask them to:
identify the likely bottlenecks
propose what to measure first
suggest two quick fixes
suggest one longer-term architecture improvement
This tests real backend judgement.
It also mirrors actual work far better than abstract algorithm puzzles, which we continue to inflict on people because apparently tradition is just peer pressure from dead hiring managers.
Why this matters for AI and fintech teams
AI and fintech products make performance more complex.
In AI systems, you often have:
model calls
embeddings
retrieval
document processing
agent workflows
streaming responses
background jobs
external providers
In fintech systems, you often have:
calculations
audit logs
permissions
data versioning
Excel workflows
reconciliations
scenario modelling
financial reporting
strict correctness requirements
Put those together and you get a serious engineering challenge.
You need speed, but you also need correctness, traceability, reliability, and user trust.
That is exactly why top startups in this space need exceptional engineers rather than generic “Python API experience.”
Quick Python watch
A few useful updates from the last 7 days:
Python security releases for 3.12, 3.11 and 3.10
Python 3.12.14, 3.11.16 and 3.10.21 were released on 12 August as security releases. These versions are now in security-fix-only mode, so the releases are source-only.
The security content covered a wide range of areas, including tarfile, webbrowser, http.client, wsgiref, xml, cookies, configparser, csv, html.parser, tomllib, and compression modules.
The practical takeaway: if your team is still on 3.10, 3.11, or 3.12, this is not trivia. You need a clear runtime and patch strategy.
Python Packaging Council candidates announced
The first Python Packaging Council election now has 17 nominees for 5 open seats.
That matters because Python packaging is no longer a side issue. Tooling, standards, dependency management, build backends, PyPI, metadata, lockfiles, and installer behaviour all affect real engineering teams.
If you run Python in production, packaging governance is not just community admin. It shapes the tooling your team relies on.
Python 3.15 release candidate phase
Python 3.15.0rc1 is now in release-candidate phase, with no ABI changes expected from this point in the 3.15 series. Third-party maintainers are being encouraged to prepare projects and publish Python 3.15 wheels ahead of final release.
If you maintain libraries, internal packages, or deployment tooling, now is the time to test.
Job of the week
AI Engineers and Software Engineers
AI startup | Central London | Financial modelling | £100k to £200k base + bonus + equity
An AI startup in central London is building an Excel plugin for serious financial modelling.
They are approaching Series A and have a very high technical bar, with 2 ICPC World Finalists on the team and a CTO from Jane Street.
This is a 5-days-per-week onsite role in central London for engineers who want to build high-impact software in a demanding technical environment.
Package and setup
£100k to £200k base
Bonus
Equity
5 days per week onsite in central London
Series A around the corner
AI startup building financial modelling software
2 ICPC World Finalists on the team
CTO previously at Jane Street
What they need
Exceptional software engineering or AI engineering ability
Evidence of top-percentile technical skill
Strong product and systems judgement
Ability to work quickly without lowering quality
Interest in AI, finance, spreadsheets, modelling, automation, and high-precision workflows
Strong ownership and high agency
Comfortable working in a high-intensity onsite startup environment
Strong signals could include:
elite startup experience
big tech background
trading or quant-style environments
competitive programming
exceptional academic background
strong AI product experience
high-quality personal projects
experience building complex tools for demanding users
This is a strong opportunity for engineers who want to build serious software for financial users, work with a highly technical team, and join before the next funding round.
Outro
This week’s Python signal is simple:
Stop worshipping synthetic benchmarks.
The best engineers do not ask which framework wins a toy test. They ask what the system actually does, what matters to users, where the bottleneck is, and how to measure it properly.
Performance is not a leaderboard.
It is a production behaviour.
Open question for debate: what matters more when choosing a Python framework, raw speed, ecosystem maturity, or how well the team understands the workload?
Hiring? Contact
Josh Smith
Email: [email protected]
Phone: 01727 225 552