DEV Community: Frank Snelling

What MongoDB taught me about Postgres.

Frank Snelling — Sun, 22 Feb 2026 20:02:49 +0000

Using MongoDB arguably taught me more about Postgres than using Postgres did.

Hear me out. Previously, my knee-jerk reaction was to always opt for Postgres when starting a new project. Honestly — reasonably safe bet. But only using Postgres limited my understanding of it — as well as its benefits and its limitations.

Sounds weird to say I learnt more about something by not using it. But it's true — and that's why I'm planning this as the first article of a series. Because I genuinely learnt so much from not using Postgres.

How did I end up using MongoDB to start with?

Well, my current startup had already opted for MongoDB when I started. This largely came down to the experience on the ground, as well as the fact that the schema was rapidly evolving. This is well suited to a document-based database where schema flexibility is effectively unlimited.

But this flexibility came at a cost.

At first, it was a real joy not having a migrations-folder-of-death which harbored the scars of months of schema discovery in hundreds of back-and-forth migrations. Schema changes were fast and — when coupled with Pydantic — also continued to ensure a high-level of consistency across the codebase.

Nothing broke. The system always continued running. But it did become progressively slower and more expensive. Without rigid schemas, repeated validation was required in application code, not just on writes but also on reads.

Once Pydantic validation was happening at scale the CPU cost in our services became quickly noticeable. This was exacerbated by the fact that our validation relied on full models, limiting the effective use of projection. Simple queries started turning into full-document reads.

I suddenly began to appreciate the intentional rigidity of Postgres. Keeping validation right next to the data is efficient — not only because it is optimized, but because validation only happens once. And Postgres constraints are powerful, turning assumptions into guarantees.

That being said, it's also nice in a lot of ways to have validation close to the business logic. If we had handled migrations better, the need for defensive and expensive application code could have been reduced. And don't forget MongoDB schema validation — this is a feature I underutilized.

From my initial joy at the flexibility of MongoDB I quickly learnt an important truth. Schema discipline doesn't disappear — but you can choose whether it lives in your application code or in the database.

lru_cache vs singleton in Python — they're not the same thing.

Frank Snelling — Thu, 12 Feb 2026 22:58:05 +0000

It's common to see @lru_cache used for quick singletons in Python. As you might guess from the name — that's not the intended purpose of the function. But that doesn't necessarily mean this opportunistic "trick" is bad. Just that there are subtle differences between a classic singleton and the least recently used cache.

Using `@lru_cache` for singletons has a number of benefits.

Instantiation is lazy, meaning you don't waste resources creating an instance that isn't used.
Less boilerplate, more readable. A simple decorator is all you need, rather than a verbose class.

But it also has important drawbacks, especially when instantiation is slow. This is for two key reasons.

1. Performance

If instantiation is not instant, lazily creating your singleton can cause unnecessary delays. For example, in a FastAPI app, it isn't ideal if your first request is burdened with multiple long-running instantiations. These could be eagerly created during application startup.

2. Exactly-once guarantee

The @lru_cache decorator is explicitly documented as thread-safe in the sense that its internal state will not be corrupted under concurrent access. But this does not guarantee a singleton factory or an "initialise-exactly-once" lifecycle contract. If the function is called twice with the same value before the value is computed and cached you could end up with multiple distinct objects created for the same key. In other words: not a singleton.

The risk of this race condition is generally negligible. But the risk is greater for long-running instantiations.

So, when is it definitely bad to use `@lru_cache` as a singleton?

Multiprocessing, where the cached object itself spawns worker processes, is a good example (e.g., ProcessPoolExecutor). In this case, instantiation requires due-diligence and careful lifecycle management.

If the process pool is created lazily, the first request will bear the full brunt of spawning — spiking latency. Also, if excess pools instantiate excess child processes, this can lead to unpredictable behaviour or unnecessary CPU and memory usage. The long-running nature of spawning not only compounds the latency issue, but increases the risk of multiple pools being created.

Another consideration is teardown. While a classic singleton pattern will gracefully close clients, @lru_cache does not include a hook to terminate deterministically. Again, not always a problem — but generally not ideal for multiprocessing.

With this in mind, is it ever ok to use `@lru_cache` for singletons?

I would argue yes. But with an important caveat:

You must accept that multiple distinct instances could be created in edge cases.

In many cases this is acceptable. For example, an unused database client is not going to hurt anyone. But in certain cases this can lead to subtle, yet dangerous, behaviour.

A good rule of thumb:

Use @lru_cache(maxsize=1) for lightweight objects where extra instances are harmless.
Use lifespan (or classic singleton patterns) for anything with a real lifecycle, requiring controlled startup and teardown.

A purist might argue that using lru_cache is not the right choice for lifecycle management. But in the words of The Zen of Python:

"Special cases aren't special enough to break the rules. Although practicality beats purity."

from typing import FinallyAnExplanation

Frank Snelling — Sat, 31 Jan 2026 09:20:52 +0000

Typing in Python has been a long evolution. A long evolution attempting to reconcile the flexibility of dynamic typing with the safety of static typing.

Quoting from The Zen of Python (PEP 20), I would definitely argue that this principle:

"There should be one — and preferably only one — obvious way to do it."

does not hold true for typing in Python. There is definitely not one way to do typing and the right way is definitely not obvious — unless you take the time to understand its evolution. Which is exactly what we're going to do.

So without further ado, here are some "typing quirks" in Python and how to know when to use what. By using the most modern approach for your project, you can prevent backwards compatibility becoming an eternal migration.

But first. Let's establish two key terms for this discussion.

Typing: Typing is describing the intended shape and behaviour of values. It can be done in many ways, such as using str or int to indicate expected types. Typing is optional in Python and does not change runtime behaviour.
Annotation: An annotation is metadata attached to code via : or ->. It's stored in an object called __annotations__. The most common thing placed in an annotation is a type (but it can store other stuff too).

my_var: int = 3

Here, my_var is annotated as the type int.

During static time, before Python runs code, type-checkers like MyPy will use the typing information inside annotations to analyse your code.

When do I use the `typing` library?

Standardized typing in Python dates back to 3.5 (see PEP 484). The first standard solution to typing was a new (and aptly named) library called typing. In Python 3.5 list[int] was not a type. That's why you would use from typing import List for types lacking syntax.

These type hints took advantage of annotations, a feature which was introduced in Python 3.0 (see PEP 3107).

Typing using built-in generics, like list, was introduced in Python 3.9 (see PEP 585), while the use of | for union types was introduced in Python 3.10 (see PEP 604). Since 3.10, the only reason to use the typing library is for "typing-only" ideas like Protocol and TypedDict.

But the introduction of typing created fresh challenges.

The problem? After static time, while running code, Python would also try to evaluate types (because they're sitting in your code). This means two big problems:

Forward references: when you use a class (or model or method) before declaring it.
Circular imports: when two classes (or models or methods) import each other, causing a deadlock.

Circular imports were addressed soon after the initial release of 3.5.

PEP 484 goes into a lot more detail about this issue and proposes a solution(s), which was introduced in 3.5.2 (see reference):

from typing import TYPE_CHECKING

TYPE_CHECKING is a variable that is True during static time and False during runtime. This lets you import modules when they're needed for static time without impacting runtime at all.

if TYPE_CHECKING:
     from myFile import myClass
     import pandas as pd

I use these two examples because they illustrate the two main uses of TYPE_CHECKING. The first is already discussed: by only importing myClass at static time we can avoid circular imports. The second use is for heavy libraries which are only needed for type checking, and would be wasteful to load in at runtime when they are not used.

However, if we don't import myClass at runtime we can't actually refer to myClass in our annotations — because runtime Python won't know it exists! When a function was defined at runtime, the actual object in the annotation was looked up and stored in __annotations__ - raising errors if it did not exist.

This is where it becomes necessary to use strings for annotations. For example:

def myFunction(myInstance: "myClass"):

By wrapping the object in strings, it would not be looked up when defined. This not only allowed devs to use TYPE_CHECKING for imports, it also prevented forward references.

Automated stringization was formalized in Python 3.7, called "postponed evaluation".

And that's all postponed evaluation is. A fancy phrase for automating something that was already being done. By including from __future__ import annotations, Python would save annotations as strings by default.

It's worth noting that future is a special module for features intended to become default in Python. PEP 563 introduced from __future__ import annotations and the idea was for this feature to become mandatory by Python 3.11.

But this was scrapped and postponed evaluation was never made default in Python.

PEP 563 was superseded by PEP 649 and PEP 749 which introduced a new concept — deferred evaluation. The reason is discussed in detail in PEP 649.

In brief, storing annotations as strings can have problems for runtime users of annotations — which may or may not be using the annotation for typing. To convert string annotations back to the original object was flaky, slow and difficult.

Interestingly, PEP 484 refers to the "hope that type hints will eventually become the sole use for annotations", which clearly never came to be. It also introduces some creative ideas for distinguishing type hints from other uses of annotations and acknowledges that storing type hints as objects does have the benefit of enabling "runtime type-checkers" (which has become very popular with Pydantic!).

So what is deferred evaluation? Doesn't "deferred" = "postponed"?

Kind of. The Oxford English Dictionary does define the adjective "deferred" as:

"Postponed, put off for a time, delayed."

But in the context of Python, postponed and deferred evaluations are different things.

Deferred evaluation does not stringize annotations but stores them without evaluating them. Each function, class, and module with annotations gets an internal __annotate__ function. Annotations are only evaluated when requested. All happening without using strings.

Now is a good time to be precise about what "evaluation" exactly means.

Evaluation means that Python determines the value of something (either by executing it or resolving it). For example:

1 + 2 # evaluates to 3 by execution

In this case:

class A:
    b: B

B is evaluated by resolution, which means finding the class B (i.e., the value of B).

Deferred evaluation does not evaluate the class B until it's explicitly needed by the users of annotations. This prevents forward references.

On the other hand, postponed evaluation is not really "postponed". Because it is evaluated. It's just evaluated as a string and then messily converted back to the type.

So — compared to postponed evaluation — deferred evaluation truly is "deferred". It is not evaluated as a string or as anything. It is simply not evaluated until someone uses the annotationlib library, which provides annotations in different formats for different static and runtime users. For example:

get_annotations(A)
# returns real Python objects 
# {"b": <class B>}

get_annotations(A, format=Format.STRING)
# returns strings
# {"b": "B"}

There's a lot of other cool tricks happening under the hood of deferred evaluation including caching and "fake globals" environments. You can read about these in the PEPs. But the key takeaway is that the need for previous workarounds is meaningfully reduced and life is easier for Python libraries who rely on annotations.

Deferred evaluation was implemented in Python 3.14. __future__ annotations is planned for deprecation when Python 3.13 reaches the end of its life (but this will likely be delayed). This highlights the importance of migrating to new techniques when possible, especially when writing fresh code in newer versions.

So if you're using Python 3.14+ and not supporting older libraries, you can forgo many of the workarounds, including:

"typesAsStrings"
__future__ annotations

One thing that is still useful in 3.14 is the typing library. Not only for typing information that does not exist as built-in generics, but also for if TYPE_CHECKING. While forward references have been addressed through deferral, circular imports remain unaddressed. The primary other options are to place import statements where they are actually used: for example, inside functions. Or to use a separate types.py module. These options are respectively non-idiomatic and fragmented.

I find my AI agent often uses a mishmash of Python typing strategies.

The reason I decided to do this deep dive was because I found my AI agents mixing various typing techniques and workarounds with no apparent correlation to the version of Python my project supports. I have a couple of theories why this happens:

If a certain typing technique (like __future__ annotations) exists already in a project — perhaps as an LLM mutation or legacy code — this may be replicated and amplified in a self-reinforcing way, even if it is not always necessary.
LLMs are generally optimized for working code. Also, LLMs will optimize for our own objectives. And it's easy for us to also optimize for working code over best practice. Using the typing library for List may be unnecessary but it will never break anything. So if you're only optimizing for working code, you might as well use List everywhere!

Regardless, these peculiarities highlight the importance of understanding the evolution of typing. Because using outdated strategies could make migration harder when things like __future__ annotations are deprecated down the line.

So, to recap:

Can I use standard typing in Python?
Yes, if you are using >3.5.

Should I use the typing library?
Only when you need to.

Should I put my types in strings?
Maybe. But probably not.

Yes, if you are using <3.7.
No, if you are using >=3.7:
- If >=3.7 and <3.14, use __future__ annotations if you need stringized annotations.
- If >=3.14 you will rarely (if ever) need stringized annotations.

Should I use if TYPE_CHECKING?
This is mainly useful in two situations:

A heavy library only needed for type checking.
Circular/forward import statements.

Getting serious about FastAPI? Here's what I've learned.

Frank Snelling — Fri, 23 Jan 2026 13:27:42 +0000

FastAPI makes building backend services easier than ever - look at this endpoint masquerading as a simple function.

@app.get("/hello")
def hello(name: str = "world") -> dict[str, str]:
    return {"message": f"Hello, {name}!"}

Compare that to the boilerplate in this Java Servlet function I got ChatGPT to write up for me:

import java.io.IOException;
import javax.servlet.http.*;

public class HelloServlet extends HttpServlet {
  @Override
  protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException {
    String name = req.getParameter("name");
    if (name == null) name = "world";

    resp.setStatus(200);
    resp.setContentType("application/json; charset=utf-8");
    resp.getWriter().write("{\"message\":\"Hello, " + name + "!\"}");
  }
}

To be fair, this simplicity is not strictly FastAPI-specific. When you consider the incredible level of abstraction provided by modern frameworks (including Java frameworks), plus the fact AI agents largely rule the world of manual coding, it can be difficult to grasp exactly what's going on under the hood of a framework like FastAPI. And when I was building simple CRUD apps, this was honestly fine. But - after being burnt a few too many times by AI (more on that) - I've been leveling up my Python skills. I don't have any intention of replacing AI, but it's very clear to me that an advanced and well-crafted backend service needs human expertise. Which means really understanding what FastAPI is doing behind the scenes (and most other async frameworks by extension).

Let me illustrate with an example. Consider this.

When I asked ChatGPT how to sandbox an under-tested simulation pipeline, it suggested spinning it up in a separate process - good instinct. The problem was where it told me to do it.

def run_simulation():
    process = multiprocessing.Process(target=run_pipeline)
    process.start()
    return {"status": "started"}

Looks fine right? Maybe not to a seasoned developer, but on first glance it definitely could seem fair enough. Deep in the codebase, this would have been a dangerous flaw leading to a new process spawned on every request. It's something you might not even realize is a problem with the low traffic of your local environment.

Luckily, I've learnt (after being caught out) never to trust code you don't understand. And now I finally had a use for that pesky lifespan() hook in main.py!

When you're writing regular-looking functions, it's easy to forget that FastAPI is executing them in a highly concurrent, event-driven environment.

Or whatever that means. It's all good to throw around these words, but it never actually helped me logically wrap my head around what's going on. So here's my explanation, grounded in actual examples for you to picture.

When you start a FastAPI service you might write something like this.

uvicorn main:app --workers 4

Specifying 4 workers just means you're running the service four times. Or eight times. Or whatever number you choose. So for the purpose of this discussion, we're talking about a single FastAPI worker/instance, but you can imagine this happening "times 4" or "times 8" respectively.

Let's start with processes and threads.

Your first "hello world" script probably executed synchronously (i.e., one line after the other). But this won't cut it if you want to serve millions of requests.

Before I discuss the nature of asynchronous frameworks, it is important to understand the concept of threads and processes. I was taught about these at university, but they always seemed a bit magical until I really understood how FastAPI (as an example), uses them in practice.

When you run a simple Python script like python script.py, the OS internally starts one process with one thread. The thread runs the script. Threads seem invisible in "normal" Python because the thread simply executes one line after the other. Internally, the thread has its own call stack (i.e., lines of code to run). I like to think of the thread as a worker.

But this can be confusing. It's important to understand that threads, which I'm calling workers, are completely distinct from the FastAPI worker, which is actually a process. In this analogy, the FastAPI worker (or process) is really more like "the factory", as it owns the resources and completes jobs using workers.

Quick side note: from the perspective of Uvicorn/Gunicorn a FastAPI instance is more of a worker, but I digress! For our purposes and for the rest of this post, a thread is a worker and a process is a factory.

Now if your factory only does one thing at a time, it probably only needs one worker. But no factory - FastAPI included - only does one thing at a time. So the natural solution is to hire more workers. Now we're approaching the way FastAPI works, but there's one more layer of complexity.

If you've ever managed a group of workers, you'll know one thing you definitely don't want is for them to be idle.

But when you're serving requests, workers will often be idle - maybe for entire seconds, while waiting for external calls (for example, from databases). Seconds might not seem like much to us, but to these hard-working threads, a lot can get done in these precious moments.

So FastAPI does something unexpected (at least it was unexpected to me the first time I internalized it!). Each FastAPI instance mainly relies on a single worker, a lone thread doing unimaginable quantities of soul-crushing work. At least for asynchronous requests, but more on that ↓

Enter the coroutine and the event loop.

Your FastAPI process exists within exactly one event loop. And the event loop manages coroutines. I like think of coroutines as jobs, incoming work. And these jobs can be paused. So the event loop is the manager of our lone thread and whenever the worker has a moment spare, the manager gives him a new job to work on.

But how does the manager know when the worker has a moment to spare? Well, this is why we use await. Every time you use this keyword, you're exposing the worker as "not busy" and saying "give him more work, he's waiting for the database to respond!" Instead of having a bunch of workers sitting around half the time, FastAPI works a single thread to the bone, never giving him an idle moment (again, with an important caveat).

I don't know about other people, but I certainly feel like I initially rote-learned where to put the keyword async and await. But if you've made it this far in my post, you'll have a much better understanding of when to use them.

Whenever we use the keyword async to define a function or an endpoint, it will be a coroutine (or a job). If you want to use await you need to use it within a coroutine, because it doesn't make sense to await a thread who's only doing one job!

So what happens if you don't use `async` to define a function?

Ok, remember the caveats about FastAPI depending on a single worker? Well this is not strictly true - only true for asynchronous endpoints. If you choose not to use async to define a function, the task will be assigned to the threadpool - not the event loop. The threadpool is a distinct mechanism, essentially a separate group of workers, ready to do work that could freeze the very important event loop. You can explicitly offload work to the threadpool too.

This helped me un-rote-learn-and-logically-understand when to use `async`.

It's important not to be too liberal with your use of async. If you have an endpoint or function that could block our lone worker for long periods of time, maybe because of CPU-heavy computation, don't use async. You don't want to burden your star worker with the grunt work at which the threadpool excels. This can lead to the event loop getting overwhelmed and spending more time organising all the jobs that come in, rather than getting them done, a vicious cycle that spikes latency.

So in my example with the risky simulation, why not use a thread rather than a process?

Using the threadpool for my under-tested simulation certainly would have taken significant grunt work away from the event loop. However, my main concern was the possibility of the simulation crashing. The event loop and the threadpool live in the same process, meaning they share memory, resources, and a Python interpreter. They are essentially operating in the same factory.

And this is where the analogy mostly breaks down. If the thread that is computing the simulation gets stuck, you might think that we can tell it to "start again". But this is not how a program runs. Unfortunately, you can't simply kill a thread in Python, as it's intertwined memory-wise and interpreter-wise with our event loop. At least, you can't do it easily. So if the simulation crashes while being run on a thread, it's bringing down the whole factory with it.

What's the solution? Give the simulation its own factory, its own process - a sandbox, if you like. The simulation now runs with its own Python instance, with its own allocation of memory and CPU that it can do with as it likes. And if the factory goes down, we can simply build a new one and get the simulation running in there. The event loop is protected and our simulation runs safely and separately.

So what was the issue with our AI suggestion at the beginning?

ChatGPT was recommending that we build a new factory (or process) every time a simulation was run. This is not only inefficient, but would eventually lead to resources being stretched thin across thousands of unused processes.

So instead, when the application starts up, we build a process(es). We only rebuild the process(es) if it (or they) time(s) out. Parentheses added because you can start more than one process at runtime.

I hope this long-winded analogy is helpful! It certainly allowed me to understand what's going on underneath the innocent-looking functions used by FastAPI. And this is important, because the framework (and by extension, probably the AI agent you're using) doesn't know your intent, so it won't stop you doing something architecturally catastrophic - that part is still on you.

Feel free to comment clarifications or your own insights in the comments!

Glossary if you get lost in the extended metaphor

Threads: I think of them as workers, completing work.
Processes: Sort of like a factory, with its own Python interpreter, memory and CPU allocation.
FastAPI instance or FastAPI worker: This is an example of a process, a specific type of factory if you will.
Coroutine: A job or work request made to the factory.
Event loop: The manager of the factory, albeit only managing a single worker.
Threadpool: A group of workers ready for grunt work.