DEV Community: Achraf Ben Hamou

How to Rename a Django Application Safely

Achraf Ben Hamou — Mon, 24 Aug 2026 15:14:47 +0000

Renaming a Django application looks simple at first: rename the directory and update the imports.

However, if the application already has migrations and data in production, renaming it can be tricky. Django uses the application name in several places, including migration history, content types, permissions, and database table names.

In this article, we'll look at a safe way to rename a Django app, especially when using PostgreSQL.

The important distinction: package name vs. app label

Before changing anything, it's important to understand that Django has several concepts related to an app's name.

For example:

myproject/
├── manage.py
├── config/
└── foo/
    ├── __init__.py
    ├── apps.py
    ├── models.py
    └── migrations/

The Python package is:

foo

And the application configuration might be:

from django.apps import AppConfig


class FooConfig(AppConfig):
    default_auto_field = "django.db.models.BigAutoField"
    name = "foo"

Django also has an app label, which is used internally by migrations and content types.

By default, the app label is derived from the last part of name.

This distinction is important because changing the Python package name does not necessarily mean that you need to change the Django app label.

Option 1: Rename only the Python package

If your main goal is to rename:

foo/

to:

bar/

while keeping the existing Django application identity, this is usually the safest approach.

Rename the directory:

foo/

to:

bar/

Then update apps.py:

from django.apps import AppConfig


class BarConfig(AppConfig):
    default_auto_field = "django.db.models.BigAutoField"
    name = "bar"
    label = "foo"

The important part here is:

label = "foo"

By keeping the old label, Django continues to recognize the application as the same application from the migration/content-type perspective.

Then update your imports and references:

from foo.models import MyModel

becomes:

from bar.models import MyModel

Also check:

INSTALLED_APPS
apps.py
urls.py
views.py
admin.py
forms.py
signals.py
Celery configuration
tests
templates
static files
management commands
any imports elsewhere in the project

For example:

INSTALLED_APPS = [
    # ...
    "bar.apps.BarConfig",
]

With this approach, you generally don't need to manually modify django_content_type or django_migrations.

This is usually the preferred solution when you simply want to rename the Python package.

Option 2: Change the Django app label as well

Sometimes you don't only want:

foo/

to become:

bar/

You also want Django to consider the application itself to have changed from:

foo

to:

bar

This is much more complicated.

For example, Django's default database table name for:

class Customer(models.Model):
    ...

may be:

foo_customer

If the app label changes to bar, Django may expect:

bar_customer

You therefore need to consider:

Migration history
Content types
Permissions
Database tables
Foreign keys and many-to-many tables
Generic relations
Existing migration files
Third-party packages referencing the old app label

Don't blindly edit `django_migrations`

A common solution found online is:

UPDATE django_migrations
SET app = 'bar'
WHERE app = 'foo';

Although this can be useful in very specific migration-management procedures, it should not be treated as the standard first step for renaming a Django application.

The django_migrations table represents Django's migration history. Its contents must remain consistent with the migration files that Django loads.

Simply changing this table without carefully changing the migration graph can result in:

migrations being considered unapplied;
migrations being applied twice;
broken migration dependencies;
inconsistent production databases.

In other words, changing the database record alone does not rename a Django application.

What about `django_content_type`?

Django stores content types using the application's app_label.

For example:

app_label = foo
model = customer

If the app label really changes to bar, existing content types may need to be updated:

UPDATE django_content_type
SET app_label = 'bar'
WHERE app_label = 'foo';

However, this should be done only if you are intentionally changing the Django app label.

You should also consider the permissions associated with these content types.

Before doing this on production, always take a database backup and test the complete migration on a copy of the production database.

Renaming database tables

If your models use Django's default table names, changing the app label can also change the table names Django expects.

For example:

foo_customer

could become:

bar_customer

With PostgreSQL, a table can be renamed with:

ALTER TABLE foo_customer RENAME TO bar_customer;

For several tables:

ALTER TABLE foo_customer RENAME TO bar_customer;
ALTER TABLE foo_order RENAME TO bar_order;

However, don't assume that every model uses <app_label>_<model_name>.

A model can define its own database table:

class Customer(models.Model):
    class Meta:
        db_table = "customers"

In this case, renaming the Django app does not require renaming the customers table.

So before writing SQL, inspect your actual database schema.

A safer migration approach

If you really need to change the app label and database table names, database changes should preferably be represented explicitly in Django migrations.

For example, you can use SeparateDatabaseAndState when the database operation and Django's model state need to be handled separately.

A simplified example:

from django.db import migrations


class Migration(migrations.Migration):

    dependencies = [
        # Your actual migration dependency
    ]

    operations = [
        migrations.SeparateDatabaseAndState(
            database_operations=[
                migrations.RunSQL(
                    "ALTER TABLE foo_customer RENAME TO bar_customer;",
                    reverse_sql=(
                        "ALTER TABLE bar_customer "
                        "RENAME TO foo_customer;"
                    ),
                ),
            ],
            state_operations=[
                # Django state operations go here.
            ],
        ),
    ]

The exact migration depends heavily on the existing project and migration history, so this should not be copied blindly into a production project.

Creating an empty migration

The original article contains a small syntax error here.

The correct command is:

python manage.py makemigrations bar --empty

or:

./manage.py makemigrations bar --empty

Notice that --empty is one option.

Not:

makemigrations bar - empty

Be careful with migration dependencies

Another important issue is migration dependencies.

For example:

class Migration(migrations.Migration):
    dependencies = [
        ("bar", "0020_auto_20230530_1535"),
    ]

This is only valid if Django actually has an application with the label bar and a migration named:

0020_auto_20230530_1535

You should never simply replace:

("foo", "0020_...")

with:

("bar", "0020_...")

without understanding how Django's migration graph will change.

Existing migrations also contain dependencies such as:

dependencies = [
    ("foo", "0019_previous_migration"),
]

If you rename the application label, these historical dependencies need to be handled consistently.

A practical recommendation

For most projects, I recommend the following strategy.

If you only want to rename the Python package

Use:

foo/ → bar/

and keep:

label = "foo"

in AppConfig.

Then update imports and application references.

This minimizes the risk of breaking your migration history.

If you absolutely need the Django app label to change

Treat it as a database and migration migration, not simply as a folder rename.

Before making the change:

Back up the database.
Test the operation on a copy of production.
Inspect all existing migrations.
Identify all database tables belonging to the application.
Check django_content_type.
Check permissions.
Check generic foreign keys.
Check third-party applications that reference the old app label.
Plan the migration graph carefully.
Deploy the database changes together with the corresponding application code.

Conclusion

Renaming a Django application is not just a matter of renaming a directory.

The safest solution depends on what you actually want to rename:

Python package
      ↓
foo/ → bar/

is relatively straightforward.

But changing:

Django app label
      ↓
foo → bar

can affect migrations, content types, permissions and database tables.

Therefore, before manually modifying tables such as:

django_migrations
django_content_type

make sure you understand which Django identity you are changing.

For an existing production application, keeping the original app label while renaming the Python package is often the least risky solution.

And, as always, test the complete procedure against a copy of your production database before deploying it.

Thanks for reading!

RPC in Python: gRPC, Protocol Buffers, and REST vs GraphQL

Achraf Ben Hamou — Mon, 24 Aug 2026 15:11:55 +0000

When building backend systems, choosing the right communication protocol can have a significant impact on performance, maintainability, and scalability.

REST is still the most common choice for public APIs, while GraphQL has become popular when clients need flexible data fetching.

But when services need to communicate efficiently with each other, another approach becomes particularly interesting: RPC, and more specifically gRPC.

In this article, we'll explore:

What RPC actually means
How gRPC works
What Protocol Buffers are
How to build a gRPC service with Python
gRPC vs REST vs GraphQL
When you should use each approach

1. What is RPC?

RPC stands for Remote Procedure Call.

The idea is simple: instead of thinking in terms of HTTP resources, we think in terms of calling a method on a remote service.

For example, with a traditional REST API, we might have:

GET /users/42

With RPC, the mental model is closer to:

UserService.GetUser(42)

The client calls a method, and the server executes that method remotely.

Of course, the method isn't actually local. The RPC framework takes care of the communication between the client and the server.

gRPC follows this model and allows a client application to call methods on another machine almost like calling local methods.

2. What is gRPC?

gRPC is an RPC framework originally developed at Google.

It allows services to communicate using strongly defined service contracts.

A typical gRPC architecture looks like this:

┌─────────────┐
│   Client    │
│   Python    │
└──────┬──────┘
       │
       │ gRPC
       │
       ▼
┌─────────────────┐
│      Server     │
│     Python      │
└─────────────────┘

Instead of manually designing HTTP endpoints and JSON payloads, we define the service contract in a .proto file.

gRPC can use Protocol Buffers as both the interface definition language and the message format.

3. Protocol Buffers: the contract

Protocol Buffers, commonly called Protobuf, are used to define the messages and services exchanged between applications.

For example:

syntax = "proto3";

service UserService {
    rpc GetUser(GetUserRequest) returns (User);
}

message GetUserRequest {
    int32 id = 1;
}

message User {
    int32 id = 1;
    string name = 2;
    string email = 3;
}

This file describes our API contract.

We have:

A UserService
A GetUser RPC method
A GetUserRequest
A User response

The important part is that the contract is language-independent.

A Python service could communicate with a Go, Java, C#, or Node.js service using the same .proto definition.

gRPC officially supports multiple languages, including Python, Go, Java, C#, Node.js, Ruby, PHP and others.

4. Building a gRPC API with Python

Let's build a very small service.

Install the dependencies

python -m pip install grpcio grpcio-tools

The official Python gRPC documentation uses grpcio for the runtime and grpcio-tools for generating Python code from .proto definitions.

Our project could look like this:

grpc-demo/
│
├── proto/
│   └── user.proto
│
├── server.py
├── client.py
└── requirements.txt

5. Define the service

Create:

proto/user.proto

with:

syntax = "proto3";

package user;

service UserService {
    rpc GetUser(GetUserRequest) returns (User);
}

message GetUserRequest {
    int32 id = 1;
}

message User {
    int32 id = 1;
    string name = 2;
    string email = 3;
}

We have now defined our API contract.

6. Generate Python code

We can generate the Python client/server code with:

python -m grpc_tools.protoc \
    -I./proto \
    --python_out=. \
    --grpc_python_out=. \
    ./proto/user.proto

This generates files similar to:

user_pb2.py
user_pb2_grpc.py

The first contains the generated Protocol Buffer message classes, while the second contains the gRPC-specific client and server code.

You normally don't edit these generated files manually.

7. Implement the Python server

Now we can implement the service.

from concurrent import futures

import grpc

import user_pb2
import user_pb2_grpc


class UserService(user_pb2_grpc.UserServiceServicer):

    def GetUser(self, request, context):
        return user_pb2.User(
            id=request.id,
            name="John Doe",
            email="john@example.com",
        )


def serve():
    server = grpc.server(
        futures.ThreadPoolExecutor(max_workers=10)
    )

    user_pb2_grpc.add_UserServiceServicer_to_server(
        UserService(),
        server,
    )

    server.add_insecure_port("[::]:50051")

    server.start()

    print("gRPC server running on port 50051")

    server.wait_for_termination()


if __name__ == "__main__":
    serve()

The generated UserServiceServicer provides the interface that our Python implementation extends.

The official gRPC Python examples follow the same general pattern: create a server, register the generated servicer, bind a port, and start the server.

8. Create the Python client

Now let's consume the service.

import grpc

import user_pb2
import user_pb2_grpc


def main():
    with grpc.insecure_channel("localhost:50051") as channel:

        client = user_pb2_grpc.UserServiceStub(channel)

        response = client.GetUser(
            user_pb2.GetUserRequest(id=42)
        )

        print(response)


if __name__ == "__main__":
    main()

The interesting part is:

client.GetUser(...)

From the developer's perspective, it looks very similar to calling a normal Python method.

Behind the scenes, however, the request is sent to another process or machine.

The gRPC Python API generates a client stub from the .proto service definition.

9. gRPC supports streaming

One of the features that makes gRPC particularly interesting for backend systems is streaming.

There are four RPC patterns:

Unary RPC

One request → one response.

Client ── Request ──> Server
Client <── Response ─ Server

Example:

rpc GetUser(GetUserRequest) returns (User);

Server streaming

One request → multiple responses.

rpc ListUsers(ListUsersRequest) returns (stream User);

Useful when a server needs to continuously send data to a client.

Client streaming

Multiple requests → one response.

rpc UploadUsers(stream User) returns (UploadSummary);

Useful for sending a stream of data to the server.

Bidirectional streaming

Multiple requests ↔ multiple responses.

rpc Chat(stream Message) returns (stream Message);

Both sides can continuously exchange messages.

gRPC's Python documentation demonstrates all four communication patterns.

10. gRPC vs REST

So when should we use gRPC instead of REST?

Let's compare them.

	gRPC	REST
Protocol	HTTP/2	Usually HTTP/1.1 or HTTP/2
Data format	Protobuf	Usually JSON
Contract	`.proto`	OpenAPI often used
Code generation	Built-in	Optional
Streaming	Excellent	More limited
Browser support	More complex	Excellent
Human-readable payload	No	Yes
Microservices	Excellent	Excellent
Public APIs	Less common	Excellent

REST is extremely convenient for public APIs.

For example:

GET /users/42

is easy to understand and easy to consume using:

curl

A JSON response is also easy to inspect:

{
    "id": 42,
    "name": "John Doe",
    "email": "john@example.com"
}

This simplicity is one of REST's biggest advantages.

11. gRPC vs GraphQL

GraphQL solves a different problem.

Instead of exposing multiple REST endpoints, GraphQL usually exposes a schema through which clients can request exactly the fields they need.

For example:

query {
    user(id: 42) {
        name
        email
    }
}

This is extremely useful when different clients have different data requirements.

For example:

Mobile App
     │
     ▼
 GraphQL
     │
 ┌───┼─────────┐
 ▼   ▼         ▼
User Order   Product
Service      Service

GraphQL is particularly attractive for frontend-facing APIs.

gRPC, on the other hand, is often a better fit when backend services need a strongly typed and efficient service-to-service contract.

12. Which one should you choose?

There isn't a universal winner.

Choose REST when:

You are building a public API
Browser compatibility matters
Simplicity is important
Human-readable JSON is useful
You want a familiar HTTP interface

Choose GraphQL when:

Clients need different subsets of data
You have complex frontend requirements
You want clients to control the shape of responses
You are building a frontend-facing aggregation layer

Choose gRPC when:

You are building microservices
You control both client and server
Strong contracts are important
Performance matters
You need streaming
You have multiple programming languages in your architecture

A common production architecture can even combine them.

For example:

                 Internet
                    │
                    ▼
              ┌───────────┐
              │ REST/API  │
              │ Gateway   │
              └─────┬─────┘
                    │
              ┌─────▼─────┐
              │ User      │
              │ Service   │
              └─────┬─────┘
                    │ gRPC
          ┌─────────┼──────────┐
          ▼         ▼          ▼
       Orders    Payments   Products
       Service    Service    Service

REST can be the external interface while gRPC handles internal service-to-service communication.

13. The biggest advantage: a contract-first approach

For me, one of the strongest advantages of gRPC isn't simply performance.

It's the contract.

With:

service UserService {
    rpc GetUser(GetUserRequest) returns (User);
}

the API contract is explicit.

From the same definition, tooling can generate client/server code.

This reduces a class of problems that can happen when API contracts are maintained manually.

Protocol Buffers also provide generated Python classes rather than requiring developers to manually serialize and deserialize every message.

14. But gRPC isn't always the right choice

There are trade-offs.

gRPC can be more complex than a simple REST API.

For example, debugging this:

Client
  │
  ▼
gRPC
  │
HTTP/2
  │
Protobuf
  │
Server

can be less convenient than inspecting a JSON REST request.

Also, browser clients typically require additional considerations such as gRPC-Web rather than directly using the standard gRPC protocol.

So choosing gRPC simply because it is "faster" is not enough.

The architecture and communication requirements should drive the decision.

15. Final thoughts

As a Python Backend Developer, understanding gRPC is valuable because modern distributed systems often involve multiple services communicating with each other.

REST remains an excellent choice for many APIs.

GraphQL is powerful when clients need flexible access to data.

gRPC becomes particularly interesting for internal service-to-service communication where strong contracts, generated code, and streaming are important.

The key lesson is:

Don't choose a protocol because it is popular. Choose it because it fits the communication problem you're solving.

For a Python backend engineer, knowing REST + GraphQL + gRPC gives you a much broader understanding of API architecture than knowing only how to build CRUD endpoints.

Resources

About the author

I'm a Python Backend Developer interested in distributed systems, APIs, microservices, databases, and backend architecture.

I'm documenting what I learn while building backend systems and exploring technologies such as Python, FastAPI, PostgreSQL, Docker, gRPC, and cloud infrastructure.

DEV Community: Achraf Ben Hamou

How to Rename a Django Application Safely

The important distinction: package name vs. app label

Option 1: Rename only the Python package

Option 2: Change the Django app label as well

Don't blindly edit django_migrations

What about django_content_type?

Renaming database tables

A safer migration approach

Creating an empty migration

Be careful with migration dependencies

A practical recommendation

If you only want to rename the Python package

If you absolutely need the Django app label to change

Conclusion

RPC in Python: gRPC, Protocol Buffers, and REST vs GraphQL

1. What is RPC?

2. What is gRPC?

3. Protocol Buffers: the contract

4. Building a gRPC API with Python

Install the dependencies

5. Define the service

6. Generate Python code

7. Implement the Python server

8. Create the Python client

9. gRPC supports streaming

Unary RPC

Server streaming

Client streaming

Bidirectional streaming

10. gRPC vs REST

11. gRPC vs GraphQL

12. Which one should you choose?

Choose REST when:

Choose GraphQL when:

Choose gRPC when:

13. The biggest advantage: a contract-first approach

14. But gRPC isn't always the right choice

15. Final thoughts

Resources

About the author

Don't blindly edit `django_migrations`

What about `django_content_type`?