mikeckennedy

Author here. I've been building data-driven apps for many years. I've long thought that ORMs are the right abstraction level for developers (still do). But it turns out Claude and friends are better with native query langages (e.g. SQL) than with relatively niche ORMs. Happy to discuss the tradeoffs. I know this pattern isn't for every project, and I'm genuinely curious where others draw the line.

A bit of feedback I've already gotten since this is a Python-leaning article is:

1. What are you crazy: Why not Pydantic? Pydantic is great for many things. I'm a bit fan. I'm just not convinced it needs to be the access layer for my DB. Most apps do many more reads than writes. You pay the cost of validation on every read, not just writes. Alternatives include using dataclass-wizard (https://github.com/rnag/dataclass-wizard) and cattrs (https://catt.rs) for validation on the way in for dataclasses without revalidating on every read.

2. Data classes don't provide runtime type checking. No they don't. If that is paramount for you, choose Pydantic (see #1for why I chose data classes ;) ). But data classes do provide type-checking time type safety. When paired with tools like cattrs and dataclass-wizard, inbound data can be type safe too.

3. This uses MongoDB examples. Fair. The pattern applies to SQL too (psycopg3 + parameterized queries + dataclasses). The core argument, that AI handles vanilla SQL better than SQLAlchemy ORM code, holds even more strongly there given how universal SQL is.

Benchmarks and runnable code are in the repo if you want to check it out.

Disappearing from AI results won't make AI go away.

I didn't tell anyone to optimize anything. I just posted numbers. It's not my fault some people are wired that way. Anytime I suggested some sort of recommendation it was to NOT optimize.

For example, from the post "Maybe we don’t have to optimize it out of the test condition on a while loop looping 100 times after all."

That's a fair point @esafak. I updated the article with something akin to the doubling chart of numbers in the original article from 2012.

It is open source, you could just look. :) But here is a summary for you. It's not just one run and take the number:

Benchmark Iteration Process

Core Approach:

- Warmup Phase: 100 iterations to prepare the operation (default)

- Timing Runs: 5 repeated runs (default), each executing the operation a specified number of times

- Result: Median time per operation across the 5 runs

Iteration Counts by Operation Speed: - Very fast ops (arithmetic): 100,000 iterations per run

- Fast ops (dict/list access): 10,000 iterations per run

- Medium ops (list membership): 1,000 iterations per run

- Slower ops (database, file I/O): 1,000-5,000 iterations per run

Quality Controls:

- Garbage collection is disabled during timing to prevent interference

- Warmup runs prevent cold-start bias

- Median of 5 runs reduces noise from outliers

- Results are captured to prevent compiler optimization elimination

Total Executions: For a typical benchmark with 1,000 iterations and 5 repeats, each operation runs 5,100 times (100 warmup + 5×1,000 timed) before reporting the median result.

It was. I updated the results to include the contained elements. I also updated the float list creation to match the int list creation.

Author here.

Thanks for the feedback everyone. I appreciate your posting it @woodenchair and @aurornis for pointing out the intent of the article.

The idea of the article is NOT to suggest you should shave 0.5ns off by choosing some dramatically different algorithm or that you really need to optimize the heck out of everything.

In fact, I think a lot of what the numbers show is that over thinking the optimizations often isn't worth it (e.g. caching len(coll) into a variable rather than calling it over and over is less useful that it might seem conceptually).

Just write clean Python code. So much of it is way faster than you might have thought.

My goal was only to create a reference to what various operations cost to have a mental model.

Why in the world would you create a soundtrack for a course? This Python + AI coding course has a few odd quiet, silent sections. Most of it is standard talking style. But when Claude is working hard, sometimes I want everyone to just see what it's doing and I want to get out of the way. This isn't a lot, but it's enough that'd rather have something interesting while Claude is working.

You can listen to and download the whole track if you're looking for some chill developer music to put on that isn't distracting.

Let me know what you think!

Thanks for the shoutout @spinningslate. :)

I want better predicability for my ai subscriptions (think Cursor, Copilot, etc). So I built this with Python, installable with uv!

AI Usage TUI: A very simple CLI util to help you avoid going over your limits in tools like Cursor, etc.

Sorry all, I didn't realize this was happening. I don't use dark mode at the OS level, just per app. Fixed.

Ah, the change was so subtle I didn't realize it was happening. I updated the site so it's nice regardless of theme (dark/light) on the OS.

That's a good point. I just redid the sample audio to include the opening section that adds that opening track that sets the stage with the positioning I put above.

I appreciate the idea.

Thanks Ben, much appreciated.

This go thin with uv is good advice for smaller projects. But as you grow with more aspects, it gets more problematic.

I ran code that way for years. But now we have 23 different services: web apps, APIs, and database servers, my code and other self-hosted services.

I would NOT run 23 projects/servers (3 versions of postgres) this way. Like so much, it depends. FWIW, the book goes into depth about these trade-offs.

It's good stuff. I've been running Granian for about a year and it's be a delight. I interviewed Giovanni (creator) on the podcast BTW.

How many people who you hire for $100 will do this themselves without AI these days?

See my comment above. In the book, I "show my work" on the math.

Yes, they are being ripped off.

A 8 CPU / 16 GB Ram server at Hetzner is $30 or so per month. It's $200+ at AWS / Azure.

Bandwidth is 4TB included from free at Hetzner, it's $92.16 / TB or $368.64 additional at AWS / Azure.

That is where the 6x comes from. It's described in detail with that math in the book BTW.

Nice. I used uwsgi -> gunicorn -> gunicorn with uvworkers -> granian. Granian is great. While not crazy popular along, it's really based on Rust's Hyper, see https://crates.io/crates/hyper Hyper has 400M downloads so safe to say it's pretty battle tested.

I interviewed the creator of Granian on Talk Python BTW.

Very cool Kumzy. Litestar is awesome, I interviewed some of the folks (you?) on the podcast. I give it some good press in that chapter.

Hey, you just run whatever backup command you would regularly do via compose.

For example, if you run `sqldump --db umami ...` in regular postgres (which is what they are using IIRC), then you run:

docker exec umami "sqldump --db umami ..."

Or something almost exactly like this (just from memory here and I wrote that script a year ago).

Fair and thanks for the extra background info.

Those "reader's briefs" are definitely AI. But they are discussed here a tad out of context. If you actually had the book and pull them down, the first track is me telling about them. It clearly says these are AI and just for fun, enjoy or skip. Here's the intro if you're interested:

https://blobs.talkpython.fm/00-readers-brief-intro.mp3?cache...

Zero percent of the text is AI generated. The image, yes, but I spent 9 months writing this book personally.

What are you talking about for dark mode on the site. There is no option to toggle the theme on the site. In the book, inside of readers like kindle on ipad, maybe.

But for the site as you mention, there is no dark mode. Is this some janky extension you use that isn't working? That's note the site's fault.

Hey Joel, please point to example of AI voices, especially sold as real, on the podcast.

Thanks sort of Ben. :) The book is 100% human written over 9 months by me. The image is AI yes, but the book is not AI slop. It may be slop, but it's my slop if that's your assessment.

Hi, see the reply to Joel just up this thread for more info on this. It is not presented as "real" it's clearly introduced as a fun AI extra.

Joel, my podcast has been going for 10 years, I've done research and an interview nearly ever week over that time period resulting in over 500 episodes. It's not AI.

What you are referring to is the Readers' brief and you're taking it out of context. If you actually went to all of them, you would find this as the very first "track":

https://blobs.talkpython.fm/00-readers-brief-intro.mp3?cache...

It clearly explains that this is an extra to the book, it's created with AI and meant to be fun. It makes minor mistakes but enjoy it if you like or just don't listen and read the book without.

Here is the transcript from that opening track in case you don't want to listen:

Hello and welcome to the Reader's Brief for the Talk Python in Production book. This is your author, Michael Kennedy. I am thrilled you're interested in the book.

This companion audio series features short, exploratory conversations around each chapter of the book. They typically range from two and a half to four minutes per chapter. You can listen to each chapter's Reader's Brief just before reading a chapter to help you get in the ideal mindset. Or you can listen afterward and let your mind wander and expand on the ideas covered in the chapter. It's all up to you. Once I neared completion of the book, I had been brainstorming how I could offer an audio version. However, there are sufficiently many code listings that are too important to the content to really support a word-for-word audio book. It would be rough to listen to me narrate a Nginx configuration file to you, for example.

Thus, I came up with the reader's brief idea. A conversation around topics of each chapter in a brief two to four minute format that adds to the book rather than a traditional spoken true audio book. I do want to set expectations a bit. The reader's briefs are spoken by AI. Very good ones, by the way. So you will hear an occasional misspoken acronym such as Nginx or SSH. But enjoy these for what they are and don't expect perfection. They're really interesting ideas and background stories and thoughts on each chapter.

I hope you find that they add value to your experience. I know they did to mine. Finally, I have added the necessary metadata to the MP3 files. You should be able to add them all to your music library and they will appear in a single album. MP3 file for all the chapters together and put chapter markers in that MP3 file. Pick which one you want. Thanks for the interest in my book. I'll be with you page by page as you learn from it. Cheers.