DEV Community: Josh Perspective

Deploying Django with Azure DevOps: A Practical CI/CD Pipeline

Josh Perspective — Mon, 07 Sep 2026 12:56:04 +0000

Getting a Django app running locally is the easy part. Getting it deployed reliably with tests running automatically, secrets handled safely, migrations applied without downtime, and a rollback path when something goes wrong is where a lot of projects still rely on manual steps and crossed fingers. I've used Azure DevOps to own deployment on a Django platform serving both web and mobile clients, and here's the pipeline structure that's held up well.

The shape of the pipeline

A solid CI/CD pipeline for Django breaks into distinct stages, each of which should fail loudly and stop the pipeline rather than letting a broken build limp forward:

Build : install dependencies, run linting
Test : Run the test suite against a real database, not sqlite-in-memory shortcuts that hide production bugs
Migrate : apply database migrations safely
Deploy : Push the new build to the target environment
Verify : A basic health check to confirm the deployment actually worked before calling it done

Here's what that looks like as an Azure Pipelines YAML file:

# azure-pipelines.yml
trigger:
  branches:
    include:
      - main

pool:
  vmImage: "ubuntu-latest"

stages:
  - stage: Build
    jobs:
      - job: BuildAndLint
        steps:
          - task: UsePythonVersion@0
            inputs:
              versionSpec: "3.12"
          - script: |
              pip install -r requirements.txt
              pip install flake8
              flake8 .
            displayName: "Install dependencies and lint"

  - stage: Test
    dependsOn: Build
    jobs:
      - job: RunTests
        steps:
          - script: |
              python manage.py test
            displayName: "Run test suite"
            env:
              DATABASE_URL: $(TEST_DATABASE_URL)

  - stage: Deploy
    dependsOn: Test
    condition: succeeded()
    jobs:
      - deployment: DeployToAzure
        environment: "production"
        strategy:
          runOnce:
            deploy:
              steps:
                - script: |
                    python manage.py migrate --noinput
                  displayName: "Apply migrations"
                  env:
                    DATABASE_URL: $(PROD_DATABASE_URL)
                - task: AzureWebApp@1
                  inputs:
                    azureSubscription: "$(AZURE_SERVICE_CONNECTION)"
                    appType: "webAppLinux"
                    appName: "$(APP_NAME)"
                    package: "$(Pipeline.Workspace)/**/*.zip"

The key structural decision here is dependsOn and condition: succeeded(); deployment simply cannot run if tests fail. This sounds obvious, but it's exactly the guardrail that gets skipped under deadline pressure if it's not built into the pipeline itself rather than left as a manual check.

Secrets: never in the YAML, never in the repo

Database URLs, API keys for partner integrations, and Django's SECRET_KEY should never appear directly in your pipeline YAML or in settings.py. Azure DevOps has variable groups and Azure Key Vault integration specifically for this:

variables:
  - group: "production-secrets"  # linked to an Azure Key Vault or secure variable group

Reference secrets in scripts as environment variables (as shown in the env: blocks above), and mark them as "secret" in the variable group UI so they're masked in pipeline logs. If you're integrating with partner APIs, a payment provider, a bank, or anything handling KYC, this isn't optional. A leaked key in a build log is a real incident, not a hypothetical one.

Migrations: the part that actually needs the most care

Running migrate automatically in a deploy pipeline is convenient, but it's also the step most likely to cause real damage if done carelessly. A migration that locks a large table, or one that's not backward-compatible with the currently-running code during a rolling deployment, can cause an outage rather than prevent one.

A few practices that matter here:

Avoid migrations that both add a NOT NULL column and remove the old one in the same deploy; split it into multiple deploys: add the column as nullable first, backfill data, then tighten the constraint in a later release. This avoids a window where old code (still running during a rolling deploy) breaks against the new schema.
Run migrations as a separate step before the new application code goes live, not simultaneously; the pipeline above does this by running migrate before the AzureWebApp deploy task, so the database is ready before traffic hits the new code.
Test migrations against a realistic copy of production data volume in staging, not just a small test database; a migration that runs instantly on 1,000 rows can lock a table for minutes on a table with millions.

Separate environments, separate pipelines (or stages)

For a platform serving real users, a single "push to main, deploy to production" pipeline is risky. A staging environment mirroring production as closely as practical catches problems before they reach real users:

stages:
  - stage: DeployStaging
    jobs:
      - deployment: DeployToStaging
        environment: "staging"
        strategy:
          runOnce:
            deploy:
              steps:
                - task: AzureWebApp@1
                  inputs:
                    appName: "$(STAGING_APP_NAME)"

  - stage: DeployProduction
    dependsOn: DeployStaging
    condition: succeeded()
    jobs:
      - deployment: DeployToProduction
        environment: "production"
        # Azure DevOps environments support approval gates here
        # require manual sign-off before production deploy proceeds

Azure DevOps environments support approval gates; you can require a manual approval step before the production stage runs, which is worth having on anything touching real user data or money, even if most of your pipeline is fully automated.

Health checks and rollback readiness

A deploy that "succeeds" according to the pipeline but leaves the app crash-looping isn't actually a successful deploy. Add a basic verification step after deployment:

- script: |
    curl -f https://$(APP_NAME).azurewebsites.net/healthz/ || exit 1
  displayName: "Verify deployment health"

Pair this with a simple /healthz/ Django view that checks database connectivity, not just that the process is running:

from django.http import JsonResponse
from django.db import connections

def health_check(request):
    try:
        connections["default"].cursor()
        return JsonResponse({"status": "ok"})
    except Exception:
        return JsonResponse({"status": "error"}, status=503)

And know your rollback path before you need it, whether that's Azure App Service's deployment slots (swap back to the previous slot instantly) or simply keeping the previous build artifact ready to redeploy. Deciding this during an incident, under pressure, is much worse than deciding it in advance.

A short checklist

Pipeline stages are ordered so deployment is gated on tests passing, not run in parallel or independently
Secrets live in Azure Key Vault or secure variable groups, never in YAML or source code
Migrations run as a distinct step before new code goes live, with backward-compatible migration patterns for zero-downtime deploys
Staging exists and mirrors production closely enough to catch real issues
Production deploys have an approval gate for anything touching money or user data
A post-deploy health check verifies the app is actually working, not just that the deploy command exited successfully
A rollback path is decided in advance, not improvised during an incident

None of this is exotic, but each piece tends to get skipped under time pressure until the day a bad migration or a leaked secret makes it very clear why it mattered. Building it into the pipeline once means it's enforced every time, not just when someone remembers to check.

[Boost]

Josh Perspective — Mon, 31 Aug 2026 11:58:55 +0000

Josh Perspective

Aug 31

Django 6.1's FETCH_PEERS: Does It Replace select_related and prefetch_related?

#python #webdev #django #programming

4 min read

Django 6.1's FETCH_PEERS: Does It Replace select_related and prefetch_related?

Josh Perspective — Mon, 31 Aug 2026 11:58:31 +0000

A while back I wrote about hunting down and fixing N+1 queries in Django using select_related and prefetch_related. Django 6.1, released this August, adds something that goes after the same problem from a different angle: fetch modes. If you haven't looked at this feature yet, here's what it actually does, and where it fits alongside the tools you're probably already using.

What fetch modes are

New in Django 6.1: when your code accesses a model field that wasn't loaded as part of the original query, Django fetches it from the database on demand. This has always been true. What's new is that you can now configure how that on-demand fetch behaves, using QuerySet.fetch_mode().

There are three modes:

from django.db import models

# The existing behavior — fetch the missing field for this instance only
books = Book.objects.fetch_mode(models.FETCH_ONE)

# New — fetch the missing field for every instance from the same queryset, in one extra query
books = Book.objects.fetch_mode(models.FETCH_PEERS)

# New — raise an exception instead of fetching anything
books = Book.objects.fetch_mode(models.FETCH_RAISE)

FETCH_PEERS: an automatic, on-demand prefetch

This is the headline feature, and it directly targets N+1 queries. Here's the classic problem again:

books = Book.objects.all()
for book in books:
    print(book.author.name)  # fires a separate query per book, without select_related

With FETCH_PEERS set on the queryset, the first time any instance in the loop accesses author, Django fetches that field for every instance that came from the same queryset, not just the one being accessed, in a single additional query:

books = Book.objects.fetch_mode(models.FETCH_PEERS)
for book in books:
    print(book.author.name)  # 1 query for books, 1 query for all authors = 2 total

100 books goes from 101 queries down to 2, without you needing to know ahead of time which relations the template or serializer will touch. This is the meaningful difference from select_related/prefetch_related: those require you to declare, upfront, exactly which relations you intend to access. FETCH_PEERS reacts to what's actually accessed, at runtime, and fixes the whole batch reactively.

Fetch modes apply to foreign keys, one-to-one fields, fields deferred via defer()/only(), and generic relations, and the mode propagates down through related objects, so setting it once on a queryset applies to the whole tree of relationships it touches, not just the top level.

FETCH_RAISE: turning a silent N+1 into a loud failure

The other genuinely useful mode is FETCH_RAISE, which raises a FieldFetchBlocked exception instead of fetching anything:

books = Book.objects.fetch_mode(models.FETCH_RAISE)
for book in books:
    print(book.author.name)  # raises FieldFetchBlocked instead of quietly querying

This is a guardrail for performance-critical code paths. The kind of endpoint where an accidental extra query per row is expensive enough that you'd rather the code fail loudly in development or CI than degrade quietly in production. If you've ever shipped an N+1 bug that only showed up once real traffic hit it, this is the tool that catches it before it ships, not after.

So does this replace select_related and prefetch_related?

Not exactly, they solve overlapping but distinct problems, and I'd still reach for the explicit tools first in most cases:

select_related/prefetch_related are declarative and upfront. You state exactly what you need, Django builds an efficient query (a JOIN for select_related, a second query for prefetch_related) for exactly that. This is still the right choice when you know your access patterns ahead of time, which, in a well-understood view or serializer, is most of the time.
FETCH_PEERS is reactive and safer as a fallback than doing nothing. It's genuinely useful in code paths where the exact fields accessed vary; for example, a generic admin view, a flexible reporting endpoint, or third-party/reusable code where you can't predict every relation that'll get touched. It turns what would've been a silent N+1 into a much cheaper 2-query pattern, without requiring you to enumerate every relation.
FETCH_RAISE is a testing and code-review tool as much as a runtime one-set it in tests or performance-sensitive views to make sure nothing is accidentally triggering per-row queries, and catch regressions before they ship.

One thing to check if you're upgrading

If you have code using bare select_related() with no arguments (which selects all non-nullable related fields), that usage is now deprecated in Django 6.1 in favor of either naming the fields explicitly or switching to FETCH_PEERS. Worth a quick search through your codebase if you're planning the upgrade. This is an easy one to miss since bare select_related() still works today, it just prints a deprecation warning.

Practical takeaway

If you're on Django 6.1 or planning the upgrade, I wouldn't rip out existing select_related/prefetch_related calls, they're still the more efficient, explicit choice where you already know your access patterns. But FETCH_PEERS is worth reaching for in the gaps: generic or flexible code paths where enumerating every relation upfront isn't practical, and FETCH_RAISE is worth adding to tests on your highest-traffic endpoints as a tripwire against future N+1 regressions.

Either way, this is a genuinely useful addition if N+1 queries have ever bitten you in production, it gives you a second line of defense that doesn't rely on remembering to audit every queryset by hand.

The N+1 Query Problem in Django: How to Spot It and Kill It Before It Kills Your API

Josh Perspective — Thu, 20 Aug 2026 18:34:30 +0000

There's a specific kind of bug that doesn't look like a bug at all. Your code works. Your tests pass. Everything returns the right data. Then you deploy, real users show up, and suddenly a page that loaded instantly in development takes three seconds in production or worse, times out entirely.

Nine times out of ten, when this happens on a Django project, the culprit is the N+1 query problem. It's one of the most common performance issues in any ORM-based application, and it's especially easy to introduce without noticing, because the code that causes it often looks perfectly reasonable.

I ran into this repeatedly while working on a platform with tens of thousands of users generating posts, comments, and messages, the kind of read-heavy, relationship-heavy data model where N+1 issues hide easily and get expensive fast once real traffic shows up.

What N+1 actually means

The name describes exactly what happens: 1 query to fetch a list of objects, then N additional queries, one per object to fetch related data. If you're rendering a list of 100 blog posts and looking up each post's author separately, that's 1 query for the posts and 100 more for the authors. 101 queries to render one page.

Here's the classic example:

# views.py
def post_list(request):
    posts = Post.objects.all()
    return render(request, "posts.html", {"posts": posts})

<!-- posts.html -->
{% for post in posts %}
  <h2>{{ post.title }}</h2>
  <p>by {{ post.author.name }}</p>
{% endfor %}

This looks completely normal. Nothing here is "wrong" in the sense of producing incorrect output. But every time the template accesses post.author, Django fires a fresh query to fetch that author from the database, because author is a foreign key that wasn't loaded up front. With 100 posts, that's 100 extra queries invisible in the code, very visible in your database load and response time.

Spotting it before your users do

The scary part of N+1 is that it's silent in development. With 10 posts and a local SQLite database on your laptop, 11 queries execute in milliseconds and nobody notices. The problem only becomes visible at scale exactly when it's most expensive to discover.

A few ways to catch it early:

Django Debug Toolbar shows you the exact number of queries executed per page, and will explicitly flag duplicate/similar queries, which is usually the fingerprint of an N+1 pattern.

django-silk or query logging useful in staging environments where Debug Toolbar isn't installed, to log query counts per request and catch regressions before they hit production.

A simple habit: any time you loop over a queryset and access a related object or reverse relation inside that loop, stop and ask whether that relation is being loaded eagerly. This single habit catches the majority of N+1 bugs before they're even written.

Fixing it: `select_related` for forward relations

For foreign key and one-to-one relationships, use select_related. It performs a SQL JOIN and pulls the related object into the same query, rather than firing a separate query per row.

posts = Post.objects.select_related("author").all()

Now post.author is already loaded when the template accesses it, no extra query per post, just the one JOIN-based query up front. This works for "forward" relationships, where the model you're querying holds the foreign key.

Fixing it: `prefetch_related` for reverse and many-to-many relations

For reverse foreign keys and many-to-many relationships, select_related's JOIN approach doesn't work the same way; instead, use prefetch_related, which runs a second, separate query for the related objects and joins them in Python rather than in SQL.

posts = Post.objects.prefetch_related("comments").all()

{% for post in posts %}
  <h2>{{ post.title }}</h2>
  <p>{{ post.comments.count }} comments</p>
{% endfor %}

This runs 2 queries total, regardless of how many posts there are: one for the posts, one for all the related comments, matched up in Python. Compare that to N+1 queries without it.

Combining both, and going deeper with `Prefetch`

Real-world querysets often need both at once:

posts = Post.objects.select_related("author").prefetch_related("comments", "tags")

For more complex cases — say, you only want to prefetch approved comments, not all of them — use the Prefetch object to customize the prefetch queryset itself:

from django.db.models import Prefetch

posts = Post.objects.prefetch_related(
    Prefetch("comments", queryset=Comment.objects.filter(approved=True))
)

This keeps the query count low while still letting you filter, order, or annotate the related data exactly as needed, useful in a comments/messaging-heavy system where you often only want a subset of related rows, not all of them.

Watch for N+1 hiding in serializers, not just templates

If you're building an API with Django REST Framework, the same problem shows up in serializers, and it's arguably easier to miss because there's no template to visually inspect.

class PostSerializer(serializers.ModelSerializer):
    author_name = serializers.CharField(source="author.name")

    class Meta:
        model = Post
        fields = ["title", "author_name"]

If the view serving this serializer doesn't call select_related("author") on the queryset, every serialized post triggers a separate query for author.name the exact same N+1 pattern, just one layer removed from where it's easy to spot. This is especially worth checking in nested serializers, where a list endpoint returning related objects (comments, tags, likes) is a very common place for N+1 to hide in an API-first project.

A quick way to verify you've actually fixed it

Don't just assume select_related/prefetch_related fixed things verify with Django's query logging in a shell:

from django.db import connection, reset_queries
from django.conf import settings

settings.DEBUG = True  # only in a dev/test shell, never production
reset_queries()

posts = list(Post.objects.select_related("author").prefetch_related("comments"))
for post in posts:
    _ = post.author.name
    _ = post.comments.count()

print(len(connection.queries))  # should be a small, fixed number, not proportional to len(posts)

If the query count scales with the number of posts, something's still triggering N+1 usually a relation you forgot to include in select_related/prefetch_related, or a nested relation two levels deep that needs its own prefetch.

A short checklist

Any loop over a queryset that accesses a related object or reverse relation is checked for eager loading
Forward foreign key / one-to-one access uses select_related
Reverse foreign key / many-to-many access uses prefetch_related
Complex prefetch filtering uses Prefetch objects rather than filtering in Python after the fact
DRF serializers are checked for the same pattern, not just templates especially nested serializers
Query counts are verified with Debug Toolbar or connection.queries before shipping, not just assumed fixed

N+1 queries rarely show up as an obvious bug, they show up as "the app feels slow" or "the database CPU spiked" days or weeks after a feature shipped. Catching the pattern while writing the code, rather than debugging it under production load, is a lot cheaper for the database and for you.

Handling Money Correctly in Django: A Guide to Decimals, Precision, and the Mistakes That Cost You

Josh Perspective — Mon, 17 Aug 2026 09:41:11 +0000

If you've ever built a feature that touches money, loan repayments, wallet balances, invoice totals, you've probably run into a subtle but expensive class of bugs: numbers that don't quite add up. A balance that's off by a cent. A total that rounds differently depending on which server processed it. These bugs rarely show up in development. They show up in production, in an audit, or in a support ticket from a confused user staring at a number that should be exact but isn't.

I ran into this directly while building the financial features on a platform integrating bank account opening and business loan repayment, real money, real KYC, real consequences for getting it wrong. Here's what I learned about doing it properly in Django.

The core problem: floats are not safe for money

The first mistake almost everyone makes at some point is storing monetary values as floats.

>>> 0.1 + 0.2
0.30000000000000004

This isn't a Python quirk it's how binary floating-point numbers work in every language that uses IEEE 754. The number 0.1 simply can't be represented exactly in binary, the same way 1/3 can't be represented exactly in decimal. For most use cases this rounding error is invisible. For money, where users expect exact arithmetic and every kobo or cent matters, it's unacceptable.

The fix is to never use FloatField for currency. Use Django's DecimalField instead.

from django.db import models

class LoanRepayment(models.Model):
    amount = models.DecimalField(max_digits=12, decimal_places=2)

DecimalField stores values using Python's Decimal type, which represents numbers exactly rather than approximating them in binary. 0.1 + 0.2 as Decimals gives you exactly 0.3, every time.

Choosing `max_digits` and `decimal_places` deliberately

It's tempting to guess at these values, but they matter more than they look. max_digits is the total number of digits stored (before and after the decimal point combined), and decimal_places is how many of those are after the point.

For most currency fields, decimal_places=2 is standard most currencies (NGN, USD, GBP) use two decimal places. But if you're dealing with interest calculations, foreign exchange, or any system doing intermediate calculations before rounding to a final amount, consider storing more precision internally (e.g., decimal_places=4 or higher) and only rounding to 2 decimal places at the point of display or final settlement. Rounding too early compounds errors across many transactions, something that matters a lot in a loan repayment system where interest accrues over time.

class LoanAccount(models.Model):
    principal = models.DecimalField(max_digits=14, decimal_places=2)
    interest_rate = models.DecimalField(max_digits=6, decimal_places=4)  # e.g. 0.0525 for 5.25%

Always use `Decimal` in Python code, never `float`

This is the mistake that gets people even after they've correctly set up DecimalField in their models. It's easy to accidentally reintroduce floats in application code:

# Wrong — mixes float and Decimal, will raise a TypeError or silently misbehave
amount = loan.principal * 1.05

# Correct
from decimal import Decimal
amount = loan.principal * Decimal("1.05")

Django will actually raise a TypeError if you try to multiply a Decimal by a float directly, which is a helpful guardrail but it's still easy to introduce floats upstream, especially when values come from external APIs (like a partner bank's account-opening or lending API) as JSON, where numbers often arrive as floats or strings.

The safe pattern is to convert incoming values immediately, and always via string, not directly from a float:

from decimal import Decimal

# If the API returns a string ideal
amount = Decimal(response_data["amount"])  # "1050.75" -> Decimal("1050.75")

# If the API returns a float, convert via str() first, never Decimal(float) directly
raw = response_data["amount"]  # 1050.75 as a float
amount = Decimal(str(raw))

Decimal(1050.75) (passing a float directly) will silently inherit the float's imprecision you'll get something like Decimal('1050.7499999999999857891452847979962825775146484375'). Converting through a string avoids that entirely.

Rounding: be explicit, and be consistent

Financial systems often need specific rounding rules round half up, round half to even (banker's rounding), always round down for fees, etc. Python's default Decimal rounding is "round half to even," which is often not what a finance team expects.

Be explicit using the quantize method:

from decimal import Decimal, ROUND_HALF_UP

def round_currency(value: Decimal) -> Decimal:
    return value.quantize(Decimal("0.01"), rounding=ROUND_HALF_UP)

Pick a rounding strategy deliberately, usually in consultation with whoever owns the compliance or accounting side of the business and apply it consistently everywhere money gets rounded. Inconsistent rounding between, say, the loan calculation service and the repayment display is exactly the kind of bug that surfaces as "why doesn't my balance match what I was charged."

Serialization: Django REST Framework and decimals

If you're exposing these fields through an API (which is likely if you're serving both a web and mobile client from the same backend), DRF's DecimalField serializer needs configuring too, or you'll get inconsistent output between environments.

from rest_framework import serializers

class LoanRepaymentSerializer(serializers.ModelSerializer):
    amount = serializers.DecimalField(max_digits=12, decimal_places=2, coerce_to_string=True)

    class Meta:
        model = LoanRepayment
        fields = ["amount"]

Setting coerce_to_string=True (the DRF default) returns the value as a string in the JSON response rather than a native JSON number. This is deliberate: JSON doesn't have a native decimal type, and many JSON parsers (including JavaScript's) parse numeric literals as floats, silently reintroducing the exact problem you avoided on the backend. Returning a string forces the client to explicitly parse it as a decimal type, which is exactly the friction you want here.

Database-level considerations

Beyond the Django model layer, it's worth checking that your actual database column type matches your intent. DecimalField in Django maps to DECIMAL or NUMERIC in most SQL databases (MySQL, PostgreSQL), which store the value as an exact fixed-point number rather than an approximation, this is what makes the whole approach work. If you're ever writing raw SQL or migrations by hand, keep the same precision and scale (DECIMAL(12,2)) as your Django field definition, since a mismatch here can silently truncate values on insert.

A short checklist

If you're building or reviewing a financial feature in Django, it's worth running through:

All monetary fields use DecimalField, never FloatField
max_digits/decimal_places are chosen deliberately, with extra precision retained for intermediate calculations if needed
All arithmetic in Python code uses Decimal, with explicit conversion via string for any values coming from external APIs
Rounding is explicit (quantize with a chosen rounding mode) and applied consistently across the codebase
API serializers return decimals as strings, not native JSON numbers
Database column types match Django field precision, especially in raw SQL or hand-written migrations

None of this is exotic, it's mostly about being deliberate rather than letting defaults or convenience quietly reintroduce imprecision. But in a system handling real repayments and real account balances, that deliberateness is the difference between a system users trust and one that generates support tickets every time a number doesn't quite add up.

DEV Community: Josh Perspective

Deploying Django with Azure DevOps: A Practical CI/CD Pipeline

The shape of the pipeline

Secrets: never in the YAML, never in the repo

Migrations: the part that actually needs the most care

Separate environments, separate pipelines (or stages)

Health checks and rollback readiness

A short checklist

[Boost]

Django 6.1's FETCH_PEERS: Does It Replace select_related and prefetch_related?

Django 6.1's FETCH_PEERS: Does It Replace select_related and prefetch_related?

What fetch modes are

FETCH_PEERS: an automatic, on-demand prefetch

FETCH_RAISE: turning a silent N+1 into a loud failure

So does this replace select_related and prefetch_related?

One thing to check if you're upgrading

Practical takeaway

The N+1 Query Problem in Django: How to Spot It and Kill It Before It Kills Your API

What N+1 actually means

Spotting it before your users do

Fixing it: select_related for forward relations

Fixing it: prefetch_related for reverse and many-to-many relations

Combining both, and going deeper with Prefetch

Watch for N+1 hiding in serializers, not just templates

A quick way to verify you've actually fixed it

A short checklist

Handling Money Correctly in Django: A Guide to Decimals, Precision, and the Mistakes That Cost You

The core problem: floats are not safe for money

Choosing max_digits and decimal_places deliberately

Always use Decimal in Python code, never float

Rounding: be explicit, and be consistent

Serialization: Django REST Framework and decimals

Database-level considerations

A short checklist

Fixing it: `select_related` for forward relations

Fixing it: `prefetch_related` for reverse and many-to-many relations

Combining both, and going deeper with `Prefetch`

Choosing `max_digits` and `decimal_places` deliberately

Always use `Decimal` in Python code, never `float`