Database DevOps is the workflow that lets a team ship schema changes, data migrations, and database configuration as safely, as reviewably, and as roll-backably as the team ships application code. It is a workflow, not a role. It is a set of practices, not a job title. The team that treats it as a workflow ships the database at the same cadence the team ships the application. The team that treats it as a role waits for the database person.
The cloud explainers treat database DevOps as a sub-discipline of platform engineering. The platform engineering treatises treat it as the platform team’s job. Both views miss the same thing. The small team that ships a real project does not have a platform engineer. The small team has three developers, a Postgres database, and a Friday afternoon deploy window. The workflow that works for the small team is the workflow that scales to the platform team. The workflow that does not work for the small team does not scale.
Table of contents
- The short version
- The four things database DevOps actually does
- Why it is a workflow, not a role
- The small-team version that actually ships
- The five things every database DevOps workflow has to get right
- The seven things the platform-engineering view skips
- The five mistakes that quietly compound
- How this fits the rest of the stack
- FAQ
The short version
Database DevOps is the workflow that takes a schema change from a pull request to a production database, in the same reviewable, automated, roll-backable way the team takes an application change. The workflow has four parts — versioned migrations, automated apply, reviewable diffs, and reversible rollback — and the parts are the same whether the team is three developers and a Postgres or fifty engineers and a fleet of managed databases. The implementation differs. The four parts do not.
The team that has the workflow ships the database at the cadence the team ships the application. The team that does not have the workflow ships the database on a Friday afternoon, with a database person, and a meeting, and a prayer.
The four things database DevOps actually does
Strip away the marketing and database DevOps is responsible for four jobs. The list is the same whether the database is Postgres, MySQL, MongoDB, or a managed service. The implementation differs. The job does not.
Versioned migrations. Every schema change is a file in the repository, with a unique version, a forward direction, and a backward direction. The file is committed, reviewed, and merged. The migration is part of the deploy. The migration is part of the history. The migration is not a thing the database person remembers to run on a Friday afternoon.
Automated apply. The migration runs as part of the deploy pipeline. The migration runs in the same environment as the application. The migration runs against the same database the application is going to talk to. The migration is not a manual step. The migration is not a “we will run it from the laptop.” The migration is a stage in the deploy.
Reviewable diffs. The migration file is a diff against the previous schema. The diff is in the pull request. The diff is in the same review the application code is in. The reviewer can see what columns are added, what indexes are dropped, what data is migrated. The reviewer does not have to read the database person’s mind.
Reversible rollback. The migration has a backward direction. The backward direction is a file in the repository. The backward direction is tested. The backward direction is one click. A failed migration rolls the database back to the previous schema. A failed migration does not leave the application talking to a schema that does not exist.
A database workflow that does all four jobs well is rare. A database workflow that does two of the four and waves at the rest is the most common kind. The filter below is for sorting one from the other.
Why it is a workflow, not a role
The cloud explainers talk about “the database DevOps person.” The job postings talk about “the platform engineer who owns the database experience.” The vendor decks talk about “the data platform team.” The job titles are real. The mental model is wrong.
The mental model is wrong because the database workflow is not separable from the application workflow. The schema change ships in the same pull request as the code that uses the new column. The migration runs in the same deploy as the new endpoint. The rollback happens in the same incident as the code rollback. The team that has a database person is the team that has a handoff. The handoff is the part that introduces the bug.
The handoff is the part the cloud explainers skip. The handoff is the part that turns “we shipped a feature” into “we shipped a feature, then we have a meeting about the schema, then we have another deploy, then we have an incident.” The handoff is the part that decides whether the database is the kind of database the team can ship to a paying customer, or the kind of database the team ships on a Friday afternoon with a prayer.
The team that treats the database workflow as part of the deploy workflow is the team that ships the database at the same cadence the team ships the application. The team that treats the database workflow as a separate workflow, with a separate person, a separate meeting, and a separate Friday afternoon, is the team that ships the database on a delay the customer is going to feel.
The small-team version that actually ships
The platform-engineering view of database DevOps is written for teams that have a platform engineer. The small-team view is written for teams that do not. The small-team view is the one that ships, and the small-team view is the one that scales.
The schema change is a file in the repository. The file is named with a timestamp and a description — 2026_06_09_add_user_email_verified.sql. The file is in the same directory as the application code, in the same repository, on the same branch. The file is the source of truth. The file is not a thing the database person has on their laptop.
The migration runs as part of the deploy. The deploy pipeline reads the migration directory, compares the migrations to a tracking table in the database, and applies the new migrations in order. The migration is a stage in the deploy, like the build and the test. The migration is not a separate step. The migration is not a thing the team has to remember to run.
The migration is reviewed in the pull request. The reviewer sees the SQL. The reviewer sees the diff against the previous schema. The reviewer can comment on the migration, suggest a better index, and reject the migration if the migration is going to lock the table for an hour. The migration is not a thing the database person reviews in isolation. The migration is a thing the team reviews together.
The rollback is one click. The team clicks a button, the platform rolls the application back to the previous version, the platform rolls the database back to the previous schema, the application is talking to a schema that exists. The rollback is not a thing the team has to debug at 3 a.m. The rollback is a property of the platform.
The small-team version is four sentences. The platform-engineering version is four hundred pages. The platform-engineering version is right about the four hundred pages. The small-team version is right about the four sentences. The team that starts with the four sentences and grows into the four hundred pages is the team that ships the project on a budget the team can plan around. The team that starts with the four hundred pages and tries to fit the project into them is the team that ships the project on a budget the team cannot.
The five things every database DevOps workflow has to get right
These are the five things that decide whether the database workflow is the one the project is going to live on for the next three years. None of them is “has a nice dashboard,” because every database workflow has a nice dashboard. The list is the operational truth.
A migration is a file, not a meeting. The migration is a file in the repository, with a name, a forward direction, a backward direction, and a reviewer. The migration is not a meeting. The migration is not a chat message. The migration is not a “we will run it on Friday.” The migration is a file.
The migration runs as part of the deploy. The migration is a stage in the deploy pipeline, like the build and the test. The migration is not a manual step. The migration is not a thing the team has to remember. The migration runs in the same environment as the application, against the same database the application is going to talk to.
The migration is reviewable in the pull request. The reviewer sees the SQL. The reviewer sees the diff. The reviewer can comment on the migration, suggest a better index, and reject the migration if the migration is going to cause an incident. The migration is not a thing the database person reviews in isolation.
The rollback is one click. The platform rolls the application back, the platform rolls the database back, the application is talking to a schema that exists. The rollback is tested. The rollback is a property of the platform, not a property of the developer.
The observability is live. The platform knows what the database is doing — the slow query, the failed migration, the exhausted connection, the locked table, the replica that is lagging. The team gets a metric, a log, an alert, and a way to fix the problem. The team does not get a “we will email you when the issue is resolved” message.
These five are the floor. Everything else is a feature.
The seven things the platform-engineering view skips
The platform-engineering view of database DevOps is right about the platform. The view is wrong about the small team. The view skips the seven things that the small team needs to know, and the small team is the team that ships the project, and the small team is the team that the platform-engineering view is supposed to serve.
The schema change is part of the feature, not part of the platform. The team that treats the schema change as part of the feature is the team that ships the feature in one pull request. The team that treats the schema change as part of the platform is the team that ships the feature in two pull requests, with a meeting in between. The platform is the runtime. The schema is the feature.
The migration runs in dev, in staging, in production. A migration that runs in dev and not in staging is a migration the team is going to discover in production. A migration that runs in staging and not in production is a migration the team is going to skip. A migration that runs in all three is a migration the team can trust.
The migration is fast. A migration that takes an hour to apply is a migration that is going to block the deploy. A migration that takes ten minutes is a migration the team can schedule. A migration that takes ten seconds is a migration the team can ship on every pull request. The team that ships the migration on every pull request is the team that does not have a Friday afternoon deploy window.
The migration is tested. A migration that is not tested is a migration the team is going to discover at 3 a.m. The test runs in CI, against a database, against a schema. The test catches the migration that drops a column the application is still using, the migration that adds a column without a default, the migration that locks a table for an hour.
The secrets are scoped. A migration that needs a database password is a migration that has a secret. The secret is in the platform, not in the repository, not in the build artifact, not in the log pipeline. The platform owns the secret. The team owns the rotation.
The team that does the migration is the team that owns the schema. The team that owns the schema is the team that wrote the application. The team that wrote the application is the team that knows what the schema is for. The team that does not own the schema is the team that is going to add a column the application does not use, drop a column the application depends on, and rename a table the application references.
The migration is a habit, not a hero. A migration that requires a hero is a migration the team is going to skip. A migration that is a habit is a migration the team ships on every pull request. The habit is the workflow. The habit is the part the platform makes frictionless.
The five mistakes that quietly compound
A short, opinionated list of mistakes that have actually cost real teams real money on real projects. None of them are dramatic. They are the boring ones.
Treating the migration as a meeting. The migration is a file in the repository. The migration is not a meeting. The migration is not a chat message. The migration is not a “we will run it on Friday.” The team that treats the migration as a meeting is the team that has a meeting every time the schema changes, and the team that has a meeting is the team that does not have time to ship the schema.
Treating the database as a separate project. The database is part of the project. The schema is part of the feature. The migration is part of the deploy. The team that treats the database as a separate project is the team that has a database person, and the database person is the team that ships the schema on a delay the customer is going to feel.
Treating the rollback as a one-time event. The rollback is not a one-time event. The rollback is a property of the platform. The rollback is tested. The rollback is one click. The team that treats the rollback as a one-time event is the team that has a rollback that has not been touched in six months, a rollback that nobody has tested, and a rollback that does not work the first time the team needs it.
Treating the secrets as environment variables. The secrets are not environment variables. The secrets are values that the team rotates, that the platform stores, that the migration reads at apply time, and that the build artifact, the log pipeline, and the repository never contain. A team that treats the secrets as environment variables is a team that has a secret in a log line, a secret in a build artifact, a secret in a Slack channel, and a secret in a developer’s .env file.
Picking the platform for the dashboard. A team that picks a platform because the dashboard is the prettiest is a team that is going to be unhappy with the migration story, the rollback story, the secrets story, the observability story, and the bill. The dashboard is the part of the platform the team looks at. The bill is the part of the platform the team pays for.
How this fits the rest of the stack
Database DevOps is not the whole stack. The stack is the application, the database, the cache, the object store, the worker, the static site, the domain, the TLS certificate, and the way all of those pieces are observed. The database workflow is the part of the stack that owns the schema, the migrations, the rollback, and the observability of the data layer.
The services layer is the part of the platform that handles the application, the build, the deploy, the health check, and the rollback — the same deploy pipeline that runs the migration. The database layer is the part of the platform that handles the managed Postgres, the backups, the connection pooling, the point-in-time recovery, and the connection pooling the application talks to. The static layer is the part of the platform that handles the static site the database feeds.
The shape of the stack matters. A stack that splits the application from the database from the schema workflow from the observability into four different consoles is a stack that punishes the team for having a real project. A stack that lets the team see the whole picture — the application, the database, the migration, the rollback, the logs — is a stack that respects the team’s time.
For a team that wants to see the full cost of the data layer before it commits, the RunxBuild hosting calculator shows the line items together. The service, the database, the storage, the build minutes, the bandwidth — each one is a separate number, and the team’s mental model for the platform is the sum of those numbers. The data layer is the line item the team is going to think about most, and the calculator is the tool that makes the line item honest.
FAQ
What is the difference between database DevOps and platform engineering?
Database DevOps is the workflow that lets the team ship schema changes as safely as the team ships code. Platform engineering is the team that builds the internal platform the developers use. The two overlap when the platform engineering team owns the database workflow, but the database workflow can exist without a platform engineering team. A small team can have a database workflow without a platform engineering team. A large team can have a platform engineering team without a database workflow. The two are independent.
What is the difference between database DevOps and a DBA?
A DBA (database administrator) is a role. Database DevOps is a workflow. The team that has a DBA and not a database workflow is the team that ships the database on a delay the customer is going to feel. The team that has a database workflow and not a DBA is the team that ships the database at the cadence the team ships the application. The two are not mutually exclusive. The small team has the workflow and not the DBA. The large team has both.
Do I need a database DevOps tool?
The tool is not the workflow. The workflow is the four parts — versioned migrations, automated apply, reviewable diffs, reversible rollback. The tool is the part of the platform that makes the four parts frictionless. A team that has the workflow without the tool is a team that has a custom script that has not been touched in six months. A team that has the tool without the workflow is a team that has a dashboard the team does not use.
How do I start with database DevOps?
Start with the four files. The first file is the migration directory. The second file is the first migration. The third file is the rollback. The fourth file is the test. Add the four files to the repository, add the migration as a stage in the deploy pipeline, and ship the first migration. The team that ships the first migration is the team that has a database workflow. The team that has not shipped the first migration is the team that has a plan.
Is database DevOps only for relational databases?
No. Database DevOps is a workflow that applies to any database the team ships schema changes for. The workflow works for Postgres, MySQL, MongoDB, DynamoDB, Firestore, and any other database where a schema change is a thing the team ships. The tools differ. The workflow does not.
What is the most common mistake with database DevOps?
The most common mistake is treating the migration as a meeting. The team that has a migration meeting every time the schema changes is the team that has a migration meeting every time the team wants to ship a feature. The team that treats the migration as a file is the team that ships the schema at the cadence the team ships the feature. The migration is a file. The migration is not a meeting.