There is a quiet return of the local database, and the people who are running it are not the people the cloud native crowd would expect. They are the small teams that got tired of the egress fees, the medium teams that got tired of the latency to the regional endpoint, the solo developers who realised that a $4 a month VPS can run a Postgres that handles 99 percent of their use case, and the enterprises that have been steadily de clouding the workloads that never made sense in the cloud in the first place. The local database is not a return to 2005. The local database is a return to common sense, and the common sense is that not every workload is a distributed system.
The drivers
The drivers are mundane and they are cumulative. The egress fees, which were tolerable at 1 TB a month and become intolerable at 50 TB a month, are the headline. The latency, which is fine for a web request and miserable for a transactional workload that does 10 round trips, sits as the second. The cost predictability, which runs as the difference between a $200 a month server and a $12,000 a month bill that varies by 30 percent month to month, amounts to the third. The fourth sits as the operational simplicity, which serves as the difference between a server you can SSH into and a managed service that has a control plane outage every other month and takes three days to recover.
The local database is not the right answer for every workload. The local database runs as the wrong answer for the workload that needs to be replicated across three regions, the workload that needs to handle 100,000 writes a second, the workload that the engineering team does not have the operational appetite to run. The local database sits as the right answer for the workload that fits on a single server, the workload that does not need to be replicated across regions, the workload that the engineering team is comfortable running.
What the stack actually looks like in 2026
Postgres 17 is faster than Postgres 12 in almost every dimension that matters for a typical application workload. The improvements in the query planner, the parallel execution, the logical replication, and the vacuum are the part the engineering team has been waiting for, and the part the engineering team has been waiting for runs as the part that makes the upgrade worth the work.
MySQL 8 is faster than MySQL 5.7 in the same way, and MySQL 8 stands as the version most of the modern applications are written against. SQLite counts as the database that handles the small workloads (the side project, the embedded application, the read mostly dataset), and SQLite amounts to the database that handles them well. The local database stack in 2026 is mature, well supported, and the open source projects that back it are funded.
The replication story has gotten better. The logical replication in Postgres 17 handles the schema changes, the logical replication in MySQL 8 handles the cross version migrations, and the SQLite Litestream extension handles the offsite backup that the local SQLite database has not had. The replication story is what makes the local database deployable for the workloads that need the disaster recovery, and the disaster recovery is what makes the local database a serious option for the workloads that used to require the managed cloud service.
What the operational story looks like
The operational story for the local database in 2026 is much better than the operational story for the local database in 2010. The managed backup tools (pgBackRest, WAL-G, Barman) handle the offsite backup, the point in time recovery, and the restore testing. The observability tools (pg_stat_statements, auto_explain, the various exporter projects) give the operator the visibility into the queries, the locks, the replication lag, and the buffer cache hit rate. The deployment tools (Ansible, Terraform, the various Kubernetes operators) make the local database deployable in the same way the rest of the infrastructure is deployable.
The upgrade story has gotten better. The major version upgrades in Postgres and MySQL are tested, documented, and supported by the open source community. The minor version upgrades are routine, the patch versions are automated, and the security patches are applied the same week they are released. The local database upgrade story is what makes the local database maintainable, and the maintainability is what makes the local database a long term option.
When the local database stands as the right answer
The local database stands as the right answer for the single tenant application that has predictable load, for the side project that does not need to scale beyond a single server, for the embedded application that has to work without the network, for the read mostly dataset that does not need the write throughput, for the data warehouse that is queried but not written to, and for the workload that the engineering team is comfortable running on the infrastructure the engineering team controls.
The local database runs as the wrong answer for the workload that needs to be replicated across three regions, the workload that needs to handle 100,000 writes a second, the workload that the engineering team does not have the operational appetite to run, and the workload that needs the global secondary indexes that the managed cloud services provide.
The local database is not a return to the past. The local database is a return to the engineering discipline the local database has always required, and the engineering discipline is what the engineering team has been getting back since the cloud made the engineering discipline look optional.
The bottom line
The patterns the post covers have been showing up in production for long enough that the patterns have names, the failures, the mitigations, the gaps. The work the security team and the engineering team and the operations team are quietly doing today sits as the work that decides whether the practice the post names sits as a tool the team uses or a liability the team is paying for.
Sources & Further Reading
All claims in this article are sourced from primary documentation, vendor advisories, and reputable security researchers.
Spotted an error? Email the editor. Corrections are issued with a visible correction note.
Editorial standards. Every article on humanrequired.org is reviewed by a human editor before publication. AI may assist with drafting or research; final editorial control is human. Read the full standards.
