Two Apps Share a Database. Who Changes the Schema?

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

Two applications can share a database when you assign ownership of the schema and coordinate changes with both consumers. Choose one place to run migrations, list which application reads and writes each shared table, and test a schema change against both applications before removing anything they use.

Consider a customer portal and an internal operations tool. Both need the same orders. Sharing those records can avoid a synchronisation job, but the operations tool still needs to work after the portal team renames a field. A successful portal deploy only proves half of that release.

Decide how much you intend to share

Write down whether the applications share a PostgreSQL server, a database or the same tables. Those choices have different consequences. Separate databases can hold unrelated application data on one server. Sharing tables means agreeing on their meaning and coordinating changes to the records both applications use.

PostgreSQL also offers schemas to organise objects within a database. A schema name alone does not deny access; privileges determine which objects a role can use. Check the PostgreSQL schema documentation before treating a namespace as a permission boundary. Give applications only the database privileges their work requires.

Assign one migration owner

Keep the migration sequence in one repository or another named source of truth, and designate the job that applies it. Both application teams should know where to propose changes. Avoid having two unrelated startup scripts compete to manage the same tables with different migration histories.

Separate schema administration from routine application queries where your setup permits it. The portal may need to create orders, while a reporting application needs to read them. Neither requirement implies permission to drop a table. Record those distinctions alongside the connection values supplied at runtime.

Allow time for both applications to update

Plan a shared schema change around the application versions that will coexist during deployment. For a field replacement, add the new field, implement a transition for reads and writes, backfill existing records, and verify both consumers. Remove the old field only after no deployed version depends on it, including the one a rollback would start again.

Write down how you will keep the two representations consistent during that transition. A backfill alone does not handle orders created while it runs. Rehearse the sequence on isolated data, and include the previous application version in the compatibility check if you expect to roll back to it.

Record the shared database agreement

Copy this record beside the migration code and fill it in with both application owners. Keep names and responsibilities here; store passwords in the appropriate secret manager. For the release check, choose a user action in each application that touches the shared records, so a passing import cannot substitute for working software.

SHARED DATABASE AGREEMENT
Server / database / environment:
Applications and human owners:
Shared tables and their meaning:
Read and write privileges per application:
Migration repository / migration owner / execution job:

NEXT SCHEMA CHANGE
Application versions that must coexist:
Additive change:
Transition reads and writes:
Backfill and consistency check:
Portal user action to verify:
Operations user action to verify:
Previous-version compatibility result:
Condition for removing old fields:
Export location / last successful restore drill:

FAQ

Can several aidrop.it Projects use one database? Yes. On aidrop.it, a Team can link several of its Projects to a shared database resource and receive the connection as a runtime value. That connection does not coordinate your applications' schema changes; assign that responsibility in your code and release process.

Does a separate database isolate performance too? Applications using the same server still compete for its resources. Separate database names do not provide separate CPU or memory. Measure the combined workload when choosing how much capacity you need.

Can I undo a schema change by redeploying old code? Only if the current schema and data still support that code. Redeployment does not recreate dropped data. Check compatibility before release and rehearse database recovery for failures that require restoring a copy.