DEV Community: Adriano Vieira

Stop Leaking Data in Multi-Tenant Apps

Adriano Vieira — Wed, 18 Mar 2026 19:22:49 +0000

Why Your application logic isn't Enough: The Case for Database-Level Row-Level Security

You've built a robust multi-tenant SaaS. You've implemented tenant_id filters in every query, added middleware checks, and written unit tests. But here's the hard truth: Application-layer security is fragile. One missed filter, one rogue script, or a direct database connection bypasses your entire safety net.

It's time to move your security perimeter from the code to the database itself.

The Short Summary: In this deep dive, we dismantle the myth that RLS is just a "Postgres feature" and demonstrate how to seamlessly integrate Row-Level Security (RLS) into your SQLAlchemy ORM and Alembic migration workflow. We move beyond basic theory to cover the gritty details of production-ready implementation:

Why relying solely on WHERE tenant_id = ? in your code is a ticking time bomb.
Step-by-step Alembic migration scripts to enable RLS and define policies without breaking your CI/CD pipeline.
How to inject dynamic tenant context into SQLAlchemy sessions using contextvars and event listeners, ensuring your ORM queries automatically respect database policies.
Critical pitfalls like admin bypass strategies, performance indexing, and the difference between PERMISSIVE and RESTRICTIVE policies.

Stop hoping your developers never forget a filter. Start enforcing security where it matters most: at the data layer.

👉 Read the full technical guide with complete code examples, migration templates, and testing strategies on https://www.adrianovieira.eng.br/en/posts/architecture/row-level-security-sqlachemy-alembic-guide/.

High performing, Scalable APIs & Python

Adriano Vieira — Wed, 03 Dec 2025 05:21:18 +0000

The demand for fast, scalable, and easy‑to‑maintain APIs has been growing exponentially. In the same vein, developing asynchronous APIs has become essential for applications that require high concurrency and low latency.
This article presents the construction of a “simple” API focused on managing CrossFit trainings, built as a practical lab to demonstrate the full use of Python, FastAPI, and the SQLAlchemy ORM in an end‑to‑end asynchronous flow, including integration tests with PyTest.
To ensure code quality and endpoint reliability, we incorporated integrated tests using PyTest with support for asynchronous operations. These tests cover everything from validating Pydantic models to verifying the behaviour of the persistence layer, providing rapid feedback during development.
The ultimate goal is to deliver a functional prototype that illustrates best practices in architecture, API documentation, code organisation, and performance optimisation in asynchronous environments. Additionally, it offers a well‑structured, functional example that can serve as a starting point for real projects requiring high performance, simplified maintenance, and comprehensive test coverage—whether for sports training or any other application needing a modern, responsive API.

Functional Requirements

For the lab, the considered functionalities are:

A CrossFit athlete belongs to only one category (CrossFit level).
Each category can contain multiple athletes.
An athlete can train at different training centres.
Training centres can host several athletes training simultaneously.

The Technologies

Why FastAPI?

FastAPI was chosen as the primary framework for two fundamental reasons:

Declarative Model + Automatic Validation – It uses type hints and Pydantic to validate payloads with minimal extra effort.
Native Async/Await Support – Each route can be declared as async, allowing the server (Uvicorn or Hypercorn) to handle thousands of concurrent connections without blocking the event loop.

These characteristics drastically reduce boilerplate and deliver high performance out‑of‑the‑box.

Asynchronous Persistence with SQLAlchemy

SQLAlchemy provides an asynchronous driver (asyncpg for PostgreSQL).

It combines:

Full‑featured ORM – Maps Python classes to relational tables.
Asynchronous Session – CRUD operations can be executed inside Python coroutines, preserving transactional consistency.
Alembic Integration – Schema migrations are managed to take advantage of the asyncpg driver’s asynchronous implementation.

Partial example of the Domain Model:

from datetime import datetime, timezone

from sqlalchemy import DateTime, ForeignKey, String, func
from sqlalchemy.ext.asyncio import AsyncAttrs
from sqlalchemy.orm import DeclarativeBase, Mapped, mapped_column, relationship

class ORMBase(AsyncAttrs, DeclarativeBase):
    id: Mapped[int] = mapped_column(primary_key=True, autoincrement=True)

    created_at: Mapped[datetime] = mapped_column(
        DateTime(timezone=True),
        default=datetime.now(timezone.utc),
        server_default=func.now(),
    )
    updated_at: Mapped[datetime] = mapped_column(
        DateTime(timezone=True),
        default=datetime.now(timezone.utc),
        server_default=func.now(),
        server_onupdate=func.now(),
        onupdate=func.now(),
    )

class Category(ORMBase):
    __tablename__ = "category"
    name: Mapped[str] = mapped_column(String(20), unique=True, nullable=False)

    def __repr__(self):
        return f"<Category(id={self.id}, name={self.name})>"

    athletes: Mapped[list["AthleteCategory"]] = relationship(
        back_populates="categories", cascade="all, delete-orphan"
    )

API Layer with FastAPI

Main directory structure:

├── docs                # Documentation (solution design, ER, UML, OpenAPI)
├── alembic             # Database migration scripts
└── src
    ├── api
    │   ├── controllers   # Feature handlers
    │   ├── main.py       # Entry point
    │   ├── models
    │   │   ├── dto       # Pydantic models (DTO)
    │   │   └── orm       # SQLAlchemy models
    │   ├── services      # Service handlers (e.g., async DB context manager, bus)
    │   ├── setup         # Base setup (API, DB connection)
    │   └── views         # Route definitions
    └── tests
        ├── category      # Test cases for Category
        ├── conftest.py   # Test fixtures
        └── health        # Health‑check test cases

Migrations with Alembic (Asynchronous Mode)

Although Alembic is synchronous by default, it was adapted to work with the asyncpg driver. It is also part of the CI/CD pipeline, where migrations are applied before running tests or deploying to staging/production.

Partial adapted env.py example:

# ...

def do_run_migrations(connection: Connection) -> None:
    context.configure(connection=connection, target_metadata=target_metadata)
    with context.begin_transaction():
        context.run_migrations()

async def run_async_migrations() -> None:
    """Create an engine and associate a connection with the context."""
    connectable = async_engine_from_config(
        config.get_section(config.config_ini_section, {}),
        prefix="sqlalchemy.",
        poolclass=pool.NullPool,
    )
    async with connectable.connect() as connection:
        await connection.run_sync(do_run_migrations)
    await connectable.dispose()
# ...

Automated Tests with PyTest (Asynchronous)

Database fixtures could be in‑memory, but for integration testing the routines run against the actual application, validating the real database modules.
Partial example of Category test cases:

class TestCategory:
    async def test_category_post_success(
        self, aioclient: AsyncClient, category_in, category_out
    ):
        # Given – set up the stage (category_in)
        # When – perform the action
        response = await aioclient.post(url=self._CATEGORY_URL_PREFIX, json=category_in)
        # Then – verify the outcome
        assert response.status_code == status.HTTP_201_CREATED
        content = response.json()
        assert content["name"] == category_in["name"]
        category_out["id"] = content["id"]
        category_out["name"] = content["name"]
        # ...

The tests use httpx.AsyncClient to run the API in memory, ensuring the whole flow—Pydantic validation, CRUD layer, and asynchronous session—is exercised. Moreover, the CI/CD pipeline includes test‑coverage analysis and code listing.

Conclusion

I’ve shown how to combine the most modern tools in the Python ecosystem to build a fully asynchronous, testable, and production‑ready API. While the use case focuses on CrossFit training management, the presented architecture - FastAPI + SQLAlchemy + Alembic + PyTest - can be reapplied to any domain that demands:

Real‑time responses
Horizontal scalability
Simplified maintenance thanks to strong typing and automatic validation
Quality assurance through integrated testing

From here, you can extend the solution by adding JWT authentication, WebSockets for live result pushes, integrating a distributed cache (e.g., Valkey or Redis) to lower query latency, or implementing event‑driven components (e.g., Kafka) to expose data for further analysis.

Check out the source code at https://gitlab.com/adrianovieira/workout-api for the API described above.

Do you have any suggestions/tips to improve that?

Let’s keep having fun… ;)

I used the generative AI tools Grammarly and Lumo AI to support me in creating this document in English.

Concorrência em Python e o GIL

Adriano Vieira — Sun, 03 Aug 2025 22:28:59 +0000

Conheça o "GIL"

O GIL e o futuro - agora como opcional no Python-3.13 em diante.

O Python Global Interpreter Lock (GIL)[^GIL] é um mecanismo de sincronização que permite que apenas uma thread execute código Python por vez em um processo.

É uma das características mais distintivas e, por vezes, controversas da implementação padrão do Python (CPython).

Adaptado do original publicado em: https://www.adrianovieira.eng.br/posts/development/python/python-gil/

Como funciona o GIL

O GIL é essencialmente um mutex global que protege o acesso aos objetos Python,
impedindo que múltiplas threads nativas executem código Python simultaneamente.

Quando uma thread precisa executar código Python, ela deve primeiro adquirir o GIL.
Assim, outras threads ficam bloqueadas até que o GIL seja liberado.

Por que o GIL existe

O GIL foi criado para resolver problemas de gerenciamento de memória no CPython:

Proteção do contador de referências: O Python usa contagem de referências para gerenciamento de memória. Sem o GIL, múltiplas threads poderiam modificar simultaneamente os contadores de referência dos objetos, causando vazamentos de memória ou liberação prematura de objetos.
Simplicidade de implementação: O GIL simplifica significativamente a implementação do interpretador, evitando a necessidade de alocação em toda a base de código.
Proteção de extensões C: Muitas extensões C não são thread-safe, e o GIL garante que não sejam executadas concorrentemente.

Limitações do GIL

O GIL impõe restrições importantes ao paralelismo:

Threading limitado: Threads Python não podem executar código Python verdadeiramente em paralelo, limitando os benefícios do multithreading para tarefas de intensivo de CPU (CPU-intensivas).
Serialização de execução: Mesmo em sistemas multi-core, apenas um core pode executar código Python por vez.
Contenção: Em aplicações com muitas threads, a competição pelo GIL pode causar sobrecarga intensa.

E quando o GIL é liberado

O GIL é automaticamente liberado em certas situações, como:

Durante operações de I/O (leitura/escrita de arquivos, requisições de rede)
Quando executa funções C que explicitamente liberam o GIL
Em intervalos regulares durante loops longos (aproximadamente a cada 100 instruções)
Durante operações que podem bloquear (como time.sleep())

Alternativas e soluções

Multiprocessos: Usar processos separados em vez de threads contorna completamente o GIL, já que cada processo tem seu próprio interpretador.
Extensões C: Operações computacionalmente intensivas podem ser implementadas em C/Cython, que podem liberar o GIL durante a execução.
Implementações alternativas: Uso de diferentes engine como PyPy, Jython e IronPython que têm abordagens diferentes para threading, embora nem todas eliminem completamente o GIL.
Async/await: Para I/O concorrente, a programação assíncrona é frequentemente mais eficiente que threading.

O GIL pode ser desativado?

SIMMMmmm

A implementação da PEP 703 é um projeto de longo prazo que vem ocorrendo em múltiplas etapas ao longo de vários anos, onde o CPython transitará para tornar a versão sem GIL primeiro experimental, opcional, depois suportada, e finalmente a versão padrão.

Status Atual - Python 3.13

O Global Interpreter Lock pode ser desativado, e isso já é uma realidade desde o Python 3.13!

O Python-3.13, lançado em outubro de 2024, inclui suporte experimental para desabilitar o GIL através do "free-threaded mode".

No Fedora Linux, após instalar o pacote python3.13-freethreading, você pode executar a versão sem GIL usando o comando python3.13t.

O Futuro - Python 3.14

A Python-3.14, prevista para ser lançada agora em outubro/2025, já implementa a PEP 779 (PEP 779 Free-threaded Python) que traz suporte oficial sem GIL como recurso opcional. Então, caso queira usar esta versão no Fedora Linux, deve instalar o pacote python3.14-freethreading, você pode executar a versão sem GIL usando o comando python3.14t.

Have fun, pythonista

SGBD - midleware de gerenciamento de banco de dados

Adriano Vieira — Mon, 08 May 2023 22:44:11 +0000

SGBD é o Sistema Gerenciador de Banco de Dados - DBMS do inglês - é a propria aplicação (midleware) de banco.

Alguns termos usados neste domínio são:

• SGBD: o midleware (exemplos: postgresql, mariadb, mongodb etc);
• banco de dados: recurso criado no SGBD que guardará as entidades de dados (exemplos: db_myapp, db4api etc);
• tabelas: entidades de dados (exemplo: campanha, cupons etc)
• estrutura/schema de dados: os atributos ou colunas (exemploi: id, titulo, subtitulo etc),
• registros: cada "linha" e os dados existentes (exempo: 1, Ano Novo ...;

E isso sem entrar no mérito dos diferentes tipos de tecnologias de bancos (exemplo: relacional, nosql, timeseries etc).

Pop!_OS Shell on Fedora

Adriano Vieira — Wed, 26 Apr 2023 22:56:21 +0000

Pop!_OS¹ Shell integrates like a charm on Fedora 38², and change de default gnome shell.

Thanks a lot Pop!_OS Folks!

Pop!_OS Shell, on https://github.com/pop-os/shell. ↩
Fedora, on https://getfedora.org ↩