Python und Postgres: hören Sie auf, die Tabelle in den Speicher zu ziehen

Der SQL-Artikel ist die Query. Hier ist das Python, das sie nicht rückgängig macht. Ich sehe immer denselben Unfall: eine saubere FastAPI-Route, ein sauberes SQLAlchemy-Modell, und 200 MB Working Set, weil scalars().all() „alle“ hieß. Die Datenbank hat ihren Job gemacht. Die App wollte eine CSV des Warehouses.

Ich habe schon die fünf SQL-Formen statt einer Schleife geschrieben. Hier ist der Umschlag: Parameter, ein Pool, ein Timeout, und die Disziplin, keine Tabelle einzusammeln, nur weil die Dataframe-API bequem ist.

1. Das Skript, das bei 800 Zeilen lief

Lokaler Dump, pandas, ein groupby, ein to_excel. Dann zeigt es jemand auf Produktion „nur für diesen Report.“ Das ist kein Report. Das ist ein Extract der primären Datenbank in einen Prozess, den OOM killt. Ist die Antwort eine Zahl, eine Liste von fünfzig Zeilen oder eine Datei zum Streamen, sammeln Sie die Tabelle nicht. Ich schreibe die Aggregation in SQL — oder eine materialized View, wenn es täglich ist — und halte Python als Umschlag: Auth, Parameter, Format.

2. f-Strings sind keine Query-API

SELECT * FROM orders WHERE id = {order_id} per f-String zu bauen ist, wie Sie die Datenbank verschenken. Nutzen Sie $1, %(id)s oder gebundene Parameter. Jeder Treiber hat sie. SQLAlchemy text() hat sie. Ein LLM, das SQL konkateniert, ist derselbe Bug mit besseren Manieren. Dieselbe Familie: IN-Listen durch String-Join. Nutzen Sie ANY($1::int[]) oder ein echtes Bind. Ich „escape“ mich da nicht raus.

3. Das ORM-N+1, das wie sauberes Python aussieht

for invoice in invoices: invoice.customer.name ist plus eine Query pro Zeile. selectinload, ein Join, oder eine eigene Listenquery. „Loader kommt später“ — so stirbt die Listenseite nach einer Messe. Ein ORM nutze ich für Writes, die zur Arbeitseinheit passen: Bestellung plus Zeilen in einer Session. SQL für Listen und Exporte. Hybrid ist kein Scheitern. Ein ORM, das vierhundert Queries versteckt, ist es.

4. Eine Verbindung pro Request ist kein Pool

psycopg in jedem Handler zu öffnen, oder eine Engine in der Funktion zu bauen, ist, wie Sie bei einem Deploy an max_connections stoßen. Eine Engine oder ein async Pool pro Prozess. Timeout beim Acquire. Ein Checkout, der nicht über ein await zu einem anderen Dienst leben darf. asyncpg oder psycopg 3 auf dem heißen Pfad, den ich kontrolliere. SQLAlchemy, wenn das Team schon in Sessions denkt und ich Migrationen plus Identity Map brauche. Ich starte nicht drei ORMs, weil ein Tutorial Django nutzte.

5. Pandas ist eine zweite Datenbank — behandeln Sie sie so

Ein pandas-groupby auf einem Zwei-Gigabyte-Frame ist eine Warehouse-Query auf einer API-Box. Wenn Sie pandas brauchen, muss der Extract schon schmal sein: die Spalten, die Sie nutzen, der Tag, den Sie brauchen, ein COPY oder ein serverseitiger Cursor. chunksize gibt es. fetchmany gibt es. yield gibt es. pandas mag ich in Analyse-Notebooks. Nicht als Implementierung von /stats. Diese Route ist SQL plus ein typisiertes Dict.

6. Was ich wirklich ausliefere

Ein FastAPI-Router. Parameter geprüft — Daten, Workspace-Id, ein Limit. Eine Funktion, die eine parametrisierte Query ausführt, oft die Fensterformen aus dem anderen Artikel. Ein Pool. Ein Statement-Timeout, damit ein schlechter Plan den Request killt, nicht die Instanz. Kein SELECT *. Kein stilles .all() auf einer unbegrenzten Tabelle. Ein Request, eine Transaktion, außer ich habe einen benannten Grund — Outbox, eine Zahlungsübergabe. Isolation bleibt READ COMMITTED, bis ich die Anomalie nennen kann, vor der mir graut.

Fazit: Kleber ja, zweites Warehouse nein

Python ist der beste Kleber, den ich für HTTP und Jobs habe. Teuer wird es, wenn es Postgres spielt. Schreiben Sie die Query, binden Sie die Parameter, streamen oder aggregieren Sie, und halten Sie den Prozess klein. Die clevere Schleife kann warten. Die Datenbank hatte schon eine bessere — das ist der andere Artikel.