Longer-form writing from the BrevFeed team.
Reach for the wrong one of threading, multiprocessing, or asyncio and your code runs slower than the plain loop. Two workloads benchmarked across every tool show the ranking inverts between CPU-bound and I/O-bound work — one mechanism (the GIL) explains it, plus vectorization and Python 3.13/3.14 free-threading.
The same 5-million-row table written five ways — CSV, JSON Lines, Avro, Parquet, ORC — and asked the same one-column question. A file format is three decisions (text vs binary, schema vs none, row vs column), and each has a measured price: 7x in size, ~2000x in read time.
Same table, same rows, same answer — but depending on whether it's stored row-by-row or column-by-column, one query can cost 41x more bytes to read. A hands-on look at when each layout wins, measured instead of just diagrammed.
Our ETL needed billions of article-metadata lookups against ~150 GB of scholarly data, on one small EC2 box. Postgres was too slow for that workload and Redis was priced out - so we built an embedded LevelDB cache in Go, then benchmarked all three.
The eight Slowly Changing Dimension patterns — Kimball's Types 0 through 7 — walked through one customer example: what you overwrite, what you version, and what you owe the past each time a dimension changes.
A practical walkthrough of Python's @dataclass decorator — how it replaces boilerplate __init__/__repr__/__eq__ code, when to use frozen=True for immutability, avoiding the mutable-default-argument trap with field(default_factory=...), and building custom sort orders with order=True and __post_init__.
'Find the pages with no likes' is a five-minute interview question. At 500M rows on PostgreSQL, five equivalent-looking queries ranged from 3m 44s to over 6 hours. Here's why.