5 MIN READ
There is a quiet return of the local database, and the people running it are not who the cloud native crowd would expect. Small teams that got tired of the egress fees. Medium teams that got tired of the latency to the nearest regional endpoint. Solo developers who have realised that a $4 a month VPS runs a Postgres that handles the bulk of their workload. Enterprises that have been quietly de clouding the workloads that never made sense in the cloud in the first place. It is not a return to 2005. It 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. Egress fees are the headline, tolerable at 1 TB a month and unworkable at 50 TB a month. Latency to the nearest regional endpoint sits second, fine for a web request and miserable for a transactional workload that does ten round trips. Cost predictability sits third, which is the difference between a $200 a month server and a $12,000 a month bill that drifts by 30 percent between invoices. Operational simplicity sits fourth, the difference between a server the operator can SSH into at 2am 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. It runs against you if you need to replicate across three regions, handle 100,000 writes a second, or operate it without a DBA. It works for the workload that fits on a single server, does not need cross region replication, and is run by a team that is comfortable owning the database. Most workloads fit. Some do not. Knowing which is which is the actual skill.
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 query planner, the parallel execution, the logical replication, and the vacuum improvements are what the ops teams have been waiting for, and they are what makes the migration worth the work.
MySQL 8 is faster than MySQL 5.7 in the same way. Most modern applications are written against it. SQLite handles the small workloads (the side project, the embedded application, the read heavy dataset), and does it 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. Logical replication in Postgres 17 handles schema changes, the equivalent in MySQL 8 handles cross version migrations, and the SQLite Litestream extension handles the offsite backup that the embedded SQLite database has not had until recently. The combination is what makes a self hosted Postgres or MySQL a serious option for workloads that used to require the managed cloud service, because the disaster recovery piece is finally there.
What the operational story looks like
The operational story for a self hosted database in 2026 is much better than it was in 2010. Managed backup tools (pgBackRest, WAL-G, Barman) handle offsite backup, point in time recovery, and restore testing. Observability tools (pg_stat_statements, auto_explain, the various exporter projects) give the operator visibility into queries, locks, replication lag, and buffer cache hit rate. Deployment tooling (Ansible, Terraform, the various Kubernetes operators) makes the database deployable in the same way the rest of the infrastructure is deployable.
The upgrade story has gotten better too. Major version upgrades in Postgres and MySQL are tested, documented, and supported by the open source community. Minor version upgrades are routine, patch versions are automated, and security patches are applied the same week they are released. The whole package is what makes a self hosted database a maintainable long term option rather than a ticking time bomb.
When the local database stands as the right answer
Local databases fit workloads like the single tenant application with predictable load, the side project that does not need to scale past a single server, the embedded application that has to work without a network, the read heavy dataset that does not need write throughput, the data warehouse that is queried but not written to, and the workload that the team is comfortable running on infrastructure they control.
They run against you when the workload needs cross region replication, 100,000 writes a second, no in house operational appetite, or global secondary indexes that only the managed cloud services provide.
None of this is a return to the past. It is a return to the engineering discipline that a self hosted database has always required, the discipline that the cloud briefly made look optional and that the cloud bill is now quietly making look essential again.
The bottom line
Pattern has not changed in thirty years. A self hosted database is an engineering investment, not a procurement decision. Treat it as the former and the system stays stable. Treat it as the latter and the buyer finds out what a 3am corruption looks like.
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.
