At Flower Computer, we tend to think obliquely about how computers could be different. However, in the day to day slog of producing software with contemporary tools, we’ve found it heartening to dream about small efficiency gains in basic systems and how those gains would compound. Affecting a component’s efficiency when that component is under immense strain from the greater system it’s a part of will have immense impact on the system’s overall trajectory. Counterintuitively, one of the most imaginative ways of dreaming up new computers is to think about the impact of changes to subsystems.
For example: what if databases were faster and easier to use? How would that change not only affect the way computers function, but alter the lives of those who build them?
Let’s talk about Postgres
PostgreSQL is the most widely used database among developers these days (not the most widely deployed, which is probably SQLite). It’s used to store and fetch data for everything from small websites to some of the largest social networks in the world. Small improvements to Postgres, whether to the codebase itself or to tools designed to make Postgres easier to use, are felt by millions. To imagine the actual material effects of these improvements, let’s figure out how many hours per year are spent working on Postgres by developers globally.
Total estimated developer-hours in 2025
According to SlashData, as of 2025, there are roughly 47.2 million developers worldwide. Other sources cite lower numbers: JetBrains claims ~20.8 million for 2025 and Evans Data has the 2024 population at ~27 million. With some generosity to the upper bound, a rough averaging of these data points could be ~30 million developers worldwide in 2025 (do NOT cite this number).
Now that we have a rough population size to work with—how many hours of developer time were there in 2025? We will skew towards the conservative estimation in this figure as well. Although a developer may spend their whole work day thinking and considering software, they probably only get 5 or so hours of actual programming on a normal day, which is ~25 hours a week (assuming a 5-day work week). Across our whole population number of 30 million, this would be 750 million dev hours each week of last year and come to a total of 37.5 billion person-hours spent developing software in 2025 (I multiplied the weekly amount by 50 to reflect an American perspective on vacation). This total doesn’t reflect any agent-effort, although it’s safe to assume some portion of these hours were agent empowered. We are not going to estimate the quantity of tokens generated for software development in this post.
Global time spent developing with Postgres in 2025
Consider the numbers from here on to be gestural—we are doing fuzzier than napkin math, but it’s still illustrative. According to StackOverflow’s 2025 developer survey, around 49% of all respondents use Postgres. This means of all the global software development hours, roughly ~18.4 billion could be considered as Possible Postgres Hours.
OK, that’s helpful, but how many of those Possible Postgres Hours did developers actually spend on database and related areas? We are including time spent not only designing schemas and writing queries, but also time spent ORM wrangling, migrations management, backup effort, etc. Let’s consider an upper bound and a lower bound, as some devs probably spend all their time thinking about databases, and some others may use Postgres only as a simple stalwart store for some website. Let’s proceed with 11–0% of time spent developing software spent interacting with Postgres, which hopefully gives us a wide enough band to cover an average of those two extremes of Postgres usage.
This means that of the global Possible Postgres Hours (~18.4 billion), anywhere from ~0.18–1.8 billion person-hours last year were spent on Postgres development.
The same range in other values:
- 7.6–76 million person-days
- .26–2.6 million person-months
- 21–212 thousand person-years
Somewhere in those ranges is the true amount of global person-work-time spent with Postgres last year, and remember the base assumptions of hours of programming a day/week reflect work time, not total. Even assuming a conservative global hourly wage ($20), this time spent on Postgres and related software represents many billions of dollars in developer wages.
Big levers
We’ve attempted to sketch the rough human time-energy spent on Postgres last year to demonstrate the scale at which globally deployed software consumes humanity’s total available effort. Software is a funny thing, able to be duplicated with no fundamental cost, it easily propagates into all the niches where it might be useful. It also means that it’s comparatively straightforward to improve software and have those improvements propagate widely (as opposed to a car requiring transport to where an expert can enact an improvement). This is one of the reasons we are focusing on improving types of software that are widely distributed.
As an extension to our Postgres human-time cost calculation, imagine some significant improvement to Postgres (or if that seems far-fetched, a new database), that decreases the amount of work any developer needs to do by 10%. That small change would result in tens of millions of person-hours saved, not to mention the hundreds of millions of dollars that represents. If something slightly more extreme came along, maybe a sea change in database design (something that excites us but may sound like a snoozer to most), say on the order of a 30% improvement in developer experience—that represents hundreds of millions of developer time and billions of dollars saved. This doesn’t even get into the energy cost savings these improvements represent in actually running databases in data centers globally.
These are the kinds of futures we get excited about, and are working towards—improvements in the underlying systems are huge levers when propagated globally.