Why the Database Belongs to the Project, Not the Deployment

From the team behind aidrop.it — one workspace to build, host, and keep changing your code.

A database needs a lifetime that spans application releases. You may replace the web process, add a reporting service, or roll back a broken version while customers continue using the same accounts and orders. Group the database with the product that owns those records, and let individual services connect to it through explicit access decisions.

Picture a shop with a storefront and an administration app. You release the storefront several times a week and the admin once a month. Creating a new database for each release would leave you copying customer history between versions. Keeping one database resource for the project lets you change code around that history.

Separate a release from the data it uses

Deploying an application changes the process that reads and writes your records. A database migration changes the structure those processes expect. Coordinate both, especially while more than one service uses the schema. Keeping the database running across releases preserves records, but it also means older code must understand the schema that exists when it starts.

On aidrop.it, an application Service and its managed PostgreSQL resource have separate lifecycles. Rebuilding the application does not create a new PostgreSQL instance. Restarting an older application image also leaves the current data and schema in place. Code rollback needs schema compatibility before you can rely on it.

For work triggered by an accepted order, the background-job recovery drill checks what the next worker can resume after application replacement.

Use the project as the resource boundary

Group services that belong to the same product and need shared resources within one project. Connect each service to the resources its work requires. Keep unrelated customers or products in separate projects when they need separate resource ownership. A shared team account should not, by itself, grant an application access to another product's database.

aidrop.it assigns each managed backing resource to one Project. Several Services in that Project can attach to it; the platform rejects attachments from another Project. The attachment grants a network path. Your agent must also store the returned connection string as a runtime value and declare that the Service needs it. Secret access has its own boundary.

Separate database names still share a server

An instance of PostgreSQL can contain several databases, each with its own tables. Use that arrangement to organise distinct datasets while sharing the server's capacity. Separate database names do not reserve separate CPU, memory, or failure recovery. Credentials and privileges determine access; naming a second database does not establish a separate security boundary.

Within an aidrop.it Project, you can create databases inside its managed PostgreSQL instance and attach them to different Services. PostgreSQL's database hierarchy distinguishes the server, database, schema, and table. That distinction helps explain why two services can share infrastructure without sharing tables.

For the storefront and admin, sharing order tables may be intentional. Give one release process ownership of migrations and check changes against both applications. For unrelated data, separate databases may be useful. Your choice still needs an agreement about who may change the schema.

A project and data ownership map

Draw the resources your product owns before assigning migration or recovery work. Show which services share tables and which only share a PostgreSQL instance. Keep release identifiers on the application side of the map, and name the people responsible for the data below it. This example uses one database shared by two services.

PROJECT: SHOP
|
+-- Storefront Service (release A)
|     connects to shop database
|
+-- Admin Service (release B)
|     connects to shop database
|
+-- Managed PostgreSQL instance
      +-- shop database: orders, customers, products
      +-- persistent volume

ANOTHER PROJECT
  Services cannot attach to SHOP's managed resource.

OWNERSHIP
Schema migrations: <one release process and owner>
Compatibility check: <storefront and admin versions>
Database backups and restore tests: <owner and location>
Resource deletion decision: <owner>

Application rollback changes code.
Data recovery needs a separate plan.

FAQ

Can services in different aidrop.it Projects share one managed database? aidrop.it permits managed resource attachments only within the resource's own Project. Services that need that resource must belong to that Project. An external data service is a separate architecture choice with its own access and network constraints.

Does a second database provide separate performance capacity? Databases in one PostgreSQL instance share server resources. Separate names organise data; they do not provide independent memory, CPU, or failure isolation.

Does keeping the database separate make an application rollback safe? It preserves the current data while you replace code. The older application must still work with the current schema. Dropped or changed records require data recovery, not an image rollback.