We spent the last decade as an industry pretending the database was a solved problem that just needed a fresher coat of paint. Every two years a new entrant arrived with a headline benchmark, a friendly abstraction, and a SaaS dashboard. We tried most of them. Some of them shipped.
This is a note about why, in 2026, almost every new system we build at Voyager Technologies starts with a single Postgres instance, and why that decision keeps getting easier to defend instead of harder.
The thing that actually matters
The thing that actually matters in a database is not throughput, query language, or even ergonomics. It is how confident you are that the data you wrote yesterday will still be there next year, in a form you can reason about, with tooling that has not been quietly deprecated by a venture-backed roadmap.
Postgres is, unfashionably, the answer to that question for almost every application we build. It has been the answer for thirty years and will plausibly be the answer for thirty more. The dashboards that wrap it change names every eighteen months. The query planner does not.
What we tried instead
A non-exhaustive list of data layers we have shipped to production and later moved off, with the lesson each one taught us:
- A document store, for "schema flexibility." We learned that schema flexibility is a polite name for "no one has decided what the data means yet," and that the decision eventually gets made anyway, usually inside application code, where it is invisible to the next person.
- A purpose-built time-series database for an analytics use case. Worked beautifully until we needed to join its data against an entity that lived in the primary database. Then it stopped being a time-series database and started being a synchronization problem.
- A managed graph database for a recommendations product. The model fit. The client libraries were brittle in three languages. We migrated to a recursive CTE in Postgres in an afternoon and stopped paying a monthly bill.
None of these tools were bad. Each was the right answer to a question that turned out not to be the one we were actually asking.
The new defaults
For most production systems we build now, the defaults look like this:
- A single Postgres instance, on managed infrastructure (RDS, Neon, Supabase, whichever the client is already paying for).
- Logical replication for read scale, when read scale is actually demonstrated.
- JSONB columns where the shape really is open-ended, and a constraint that fails the build the moment it stops being open-ended.
- Full-text search via Postgres's own
tsvectoruntil it visibly breaks at the product's actual scale, which for most products is never. - A single migrations folder, version-controlled, with a forward-only convention and a manual review for anything that touches a constraint.
This is unromantic. It is also the configuration that has caused us the fewest 3am phone calls in the last three years.
What this is not
This is not a manifesto against new databases. The category is full of careful work and we use specialty stores when the problem genuinely requires one. Vector search for embeddings, columnar stores for warehouse workloads, in-memory caches for specific hot paths.
It is, more narrowly, a note that the question "what database should we use" has a much more confident answer than the discourse suggests, and that the cost of choosing wrong is paid by the team that inherits the system, not the team that chose it.
If you're starting a system this quarter and you don't have a specific reason to do otherwise: start with Postgres. The system you build on top of it will outlast the next four cycles of "we replaced our database with X." That is an underrated property in software.