The 2024 State of PostgreSQL survey ran for two months (September 1 through October 31), and 688 people provided responses. If you answered our questions, shared the survey on social media, or sent it to a friend—thank you! Your support is everything to us.♥️

So, sit back and grab your beverage of choice as we highlight 2024’s trends in PostgreSQL adoption, usage, and community engagement. Drum roll, please. 🥁 Here are some key insights from the 2024 State of PostgreSQL survey:

• Decline in new user adoption: There are fewer new PostgreSQL users. Only 4.1 % of respondents reported less than one year of experience with PostgreSQL, down from 8.1 % in 2023.
• AI tools on the rise: 55.3 % of PostgreSQL developers now use AI tools, a sharp increase from 36.9 % in 2023. This highlights AI's growing role in development workflows. Check our State of PostgreSQL AI blog post to learn more about how PostgreSQL users are building with AI.
• Versatility across use cases: 60 % of respondents use PostgreSQL for both personal and professional projects, a significant 20 % increase from last year.

Curious about what else we uncovered? 👀 Read on for a comprehensive dive into the State of PostgreSQL in 2024, and don’t forget to check out the full report!

The State of PostgreSQL 2024 Demographics

Let’s start by finding out who are this year’s State of PostgreSQL respondents.

What is your primary geographic location?

For another year, respondents from EMEA (Europe, Middle East, Africa) dominated the survey, representing over half of all participants. North America remains steady at 25 %, while APAC (Asia-Pacific) saw a notable dip, dropping from 12 % to 7 %. These shifts underline PostgreSQL's stronghold in EMEA and opportunities for growth in APAC.

How long have you been using PostgreSQL?

Seasoned PostgreSQL users are on the rise. Respondents with 15+ years of experience surged to 21 % from 11 % in 2023, while those with 10-15 years of experience also saw an uptick. However, new user adoption is declining sharply, with users having less than two years of experience dropping from 23.8 % in 2023 to just 12.5 % this year.

What is your current profession or job status?

The top industries using PostgreSQL remain Software/SaaS (21 %), Information Technology (18 %), and Finance/Fintech (18 %). Healthcare/Pharmaceuticals entered the top five for the first time, highlighting PostgreSQL’s growing appeal in diverse fields.

In terms of job roles, Backend Software Developers (28 %), Fullstack Developers (16 %), and Database Administrators (12 %) lead the way.

The PostgreSQL Community

How did you first find out about PostgreSQL?

Workplace environments are becoming a primary introduction point for PostgreSQL, with 30 % of respondents reporting they learned about it from colleagues or work settings. This marks a small but steady increase over last year’s 28 %. Technical forums and online communities remain stable at 6 %, while 25 % of respondents—second only to workplace discovery—can’t recall where they first encountered PostgreSQL.

Have you ever contributed to PostgreSQL?

Note: In 2024, we added Developer Relations to the multiple-choice options.

This year, the question "Have you contributed to PostgreSQL?" expanded to include multiple contribution options. While 58 % of respondents reported no contributions, the remaining 42 % have engaged with PostgreSQL in diverse ways:

• Advocacy: 17 %
• Bug reporting: 16 %
• Hosting user groups or meetups: 11 %
• Documentation: 9 %

These findings highlight the many ways developers contribute beyond just writing code, enriching the PostgreSQL ecosystem.

How would you rate your ability to connect with the PostgreSQL community? 

As opposed to last year’s numbers, respondents are finding it slightly easier to connect to the community than in previous years, with Medium (43 %) and Extremely easy (18 %) responses up by two percentage points from 2023.

A total of 384 respondents answered bonus questions, shedding light on what they like the most about the PostgreSQL community:

In your experience, what’s the best thing about the PostgreSQL community / what do you like the most?

Ecosystem and Tools

PostgreSQL’s ecosystem is one of its strongest assets, offering a rich array of tools and extensions that enhance its already robust feature set. This year’s survey explored which PostgreSQL features, complementary tools, and extensions resonate most with users. Here's what the PostgreSQL community highlighted in 2024.

What is your favorite PostgreSQL feature?

When asked about their favorite PostgreSQL features, respondents overwhelmingly pointed to extensibility, which remains PostgreSQL’s standout capability. This was followed by JSON support, prized for its flexibility in managing semi-structured data, and replication, a key enabler of high availability and fault tolerance.

👉 Interested in PostgreSQL replication? Check out our guide.

What other tools do you use that complement PostgreSQL?

Respondents highlighted the tools they most frequently use alongside PostgreSQL, with TimescaleDB emerging as the top choice for time-series and analytics workloads. This was followed by Redis, often used for caching and real-time applications, and PgBouncer, valued for its connection pooling capabilities.

👉 Get our Support team’s advice on PgBouncer.

What are your top three favorite or most frequently used PostgreSQL extensions?

The top three PostgreSQL extensions this year demonstrate its versatility across industries and use cases. For the second consecutive year, PostGIS led the pack, favored for its advanced geospatial data capabilities. Pg_stat_statements remains a favorite for performance monitoring, while TimescaleDB rounds out the top three for its time-series database capabilities.

👉 Learn how to optimize your queries with pg_stat_statements.

Read the Report

We hope you enjoyed this sneak peek of our State of PostgreSQL 2024 survey! If you’d like to learn more insights about the PostgreSQL community, including why respondents chose PostgreSQL, where they go to find jobs requiring PostgreSQL experience, and how they use AI with PostgreSQL, don’t miss our complete 2024 State of PostgreSQL report. 

Finally, a genuine word of appreciation to all the remarkable partners who have collaborated with us on this survey and helped us capture the collective experience of developers using PostgreSQL:

Community members: Jimmy Angelakos, Andrew Atkinson, Ryan Booz, Software & Booz, Elizabeth Christensen, Henrietta Dombrovskaya, Floor Drees, Stefan Fercot, Douglas Hunley, Gülçin Yıldırım Jelinek, Valeria Kaplan, Jan Karremans, Philip Marks, Doug Ortiz, Tech Bits, Steven Pousty, Anastasia Raspopina, Daniel Sarosi, Jeremy Schneider, Stefanie Janine Stölting, Shaun Thomas

Companies: Aiven, Basedash CYBERTEC, Data Bene, DataCloudGaze, Data Egret, Device Insight, EDB, KM.ON, Mark Gurry Associates, Neon, ParadeDB, PG Weekly, Plotly, ProOpenSource, simplyblock, Tembo, Timbira, Trebellar, United Manufacturing Hub, Xata

Communities: Barcelona PostgreSQL User Groups, Kadin Yazilimci, Madrid PostgreSQL User Groups, PgDay CMH, PG Day Chicago, Prague PostgreSQL Meetup

Thank you for amplifying our reach and enabling us to connect with more developers across various channels!

In 2023, PostgreSQL regained the attention it deserves as a rock-solid relational database. It was voted the most popular DB in the Stack Overflow Developer Survey and named database management system of the year by DB-Engines. Here at Timescale, we also consolidated our status as fierce PostgreSQL fans: besides having built Timescale on PostgreSQL, we believe PostgreSQL is evolving as a platform and becoming the bedrock for the future of data. So, excuse us for being a bit excited about PostgreSQL 17.

In its latest releases, we’ve watched PostgreSQL develop toward higher performance, scalability, security, and compatibility while introducing new features to meet the evolving needs of users and applications, especially enterprise ones. The improvements to privilege administration, logical replication, and monitoring are examples of that. More importantly, during this time, we contributed, managed commitfests, and created new features and products to expand it—from boosting real-time aggregation by 50,000 % to powering production AI applications.

In this blog post, we gathered Timescale contributors and enthusiasts to discuss a few of the most exciting PostgreSQL 17 commits. As we count the days until September, we’ll also examine PostgreSQL’s direction for this release. Finally, we’ll share some of our commits, as we help build up PostgreSQL as a versatile development platform for everything. 

PostgreSQL 17: Where It Came From and Where It’s Headed

Looking at the several PostgreSQL 17 commits, Aleksander Alekseev, long-time PostgreSQL contributor and Timescaler, says significant changes to modernize PostgreSQL are underway. “I believe the future of Postgres is bright,” he notes, adding that “new people are joining the project.” Perhaps influenced by the new wave of contributors, the changes to PostgreSQL 17 reflect the project’s commitment to embracing modern methodologies and adapting to the ever-evolving tech landscape

One such notable change in version 17, says Aleksander, is the decision to drop support for AIX, an operating system developed by IBM. AIX, while historically significant, has seen declining usage in recent years, prompting PostgreSQL to reallocate resources towards supporting more widely adopted platforms. This strategic move enables PostgreSQL to focus on enhancing compatibility with modern operating systems. 

While they may seem more focused today, the PostgreSQL community's efforts to make PostgreSQL a solid database for modern data needs were already visible in previous versions, including the current one, PostgreSQL 16. As a specific example, Aleksander mentions the transition from Autotools to the Meson build system. Autotools, a long-standing suite of tools for configuring, building, and installing software packages, has been a stalwart in the development process of PostgreSQL. 

However, with the advent of Meson, a contemporary build system known for its simplicity, speed, and scalability, PostgreSQL managed to streamline its development workflows. Meson offers advantages such as improved performance, easier maintenance, and better cross-platform compatibility, which PostgreSQL currently extends to its users.

What We’re Excited About PostgreSQL 17

Now that we’ve seen where PostgreSQL 17 is headed, let’s discuss some of the commits that have caught our 👀.

pg_createsubscriber

Suggested by Timescaler and PostgreSQL contributor Fabrízio de Mello, pg_createsubscriber is a new PostgreSQL 17 tool that allows users to create a new logical replica from a physical standby server. “The main advantage of this tool over a common logical replication setup is the initial data copy, which can take longer on large databases and have side effects, like autovacuum issues, due to the long-running transaction to copy data from one server to another. This tool will also help reduce the catchup phase,” explains Fabrízio.

Support for MERGE PARTITIONS and SPLIT PARTITIONS

While ALTER TABLE is a well-known statement that changes the structure of a PostgreSQL table, PostgreSQL 17 comes along with two new commands: MERGE PARTITIONS and SPLIT PARTITIONS. As the name indicates, these new DDL commands merge or split several partitions. “The current implementation has certain limitations though,” says Aleksander. “It works as a single process and holds the ACCESS EXCLUSIVE LOCK on the parent table during all operations. This is why the new DDL commands are not advisable for large partitioned tables under a high load,” he adds.

Add support for incremental file system backup

“This is another feature worth mentioning,” says Aleksander. Adding support for incremental file system backup in PostgreSQL enhances the database's ability to perform efficient and effective backups. Incremental backups only save changes made since the last backup (full or incremental). This significantly reduces the volume of data to be backed up compared to full backups, which capture the entire database. And since incremental backups involve less data, the backup process is faster, minimizing the impact on system performance and reducing downtime.

Developed by Robert Haas, Jakub Wartak, and Tomas Vondra, this commit has been struggling with stability issues, as explained by Robert on his blog. “Hopefully it won’t be reverted (as many other commits this month),” comments Aleksander.

Enable the failover of logical slots 

Picked by two Timescalers, Fabrízio and our head of Developer Advocacy, James Blackwood-Sewell, this commit by Hou Zhijie, Shveta Malik, and Ajin Cherian lets high-availability PostgreSQL use logical replication and not lose downstream data in case of a failover. Enabling the failover of logical replication slots in PostgreSQL enhances the robustness and reliability of logical replication setups by allowing logical slots to be transferred and maintained across different database instances.

Allow EXPLAIN to report optimizer memory usage

“This commit by Ashutosh Bapat is another good one,” notes Aleksander. Allowing the EXPLAIN command to report optimizer memory usage in PostgreSQL provides valuable insights into the resources consumed by the query planner and optimizer during the preparation of query execution plans.“It will allow the developer to choose the query that uses less memory,” explains Aleksander. This makes it especially helpful for those trying to fine-tune PostgreSQL’s performance.

Any on this list, really

Bruce Momjian has always been an inspiration to us—bow tie included—so we can safely say that any of the contributions on this list, which Aleksander describes as “overall performance improvements” make us excited about getting our hands on the new PostgreSQL version. 

What We Committed to PostgreSQL 17

In total, 90 commits (3.5 percent of all commits) were authored, co-authored, and/or reviewed by Timescalers during the PostgreSQL 17 cycle. 😎We’re not going to bother you by going over all of them, but we asked our team of upstreamers to name some of their personal favorites.

The SLRU move to 64-bit indexes

“Personally, I’m most excited about the series of patches that moved SLRU (simple least recently used) caches to the 64-bit indexes,” says Aleksander. While we’re not there yet, this opens the path to 64-bit XIDs, which will mitigate the problem of XID wraparound certain users face under specific workloads, such as mixing long-living OLAP (online analytical processing) transactions and OLTP (on-line transaction processing) workloads on the same PostgreSQL instance. 

Transitive comparisons

Another Timescaler who contributed to PostgreSQL was database architect Mats Kindahl. Mats helped with refactoring to ensure transitive comparisons in PostgreSQL, which brings several benefits to users. Transitive comparisons allow for more concise and intuitive query expressions, improve query optimization, enhance index usage, and facilitate data modeling, as developers can define relationships between entities more naturally.

standard_ExplainOneQuery

Mats also worked on the introduction of  standard_ExplainOneQuery in PostgreSQL 17. This addition helps ensure consistent behavior when adding explain hooks, making it easier to predict and understand the effects of explain hooks on query explanation. Developers can focus on implementing specific hooks without worrying about the nuances of query explanation behavior, leading to more efficient development processes and facilitating query performance tuning.

UUIDv7

On the reviewing front, Aleksander reviewed (along with other contributors) the partial merge of UUIDv7 support authored by Andrey Borodin. “While there are several UUIDv7 implementations available, the UUIDv7 standard is currently in draft condition,” explains Aleksander, adding that PostgreSQL will only support when the standard is finalized. Once it’s fully supported by PostgreSQL, UUIDv7 will help make time-based queries more efficient. 

Expanding PostgreSQL

Here you have it, a reflection on the direction of PostgreSQL 17, the new updates we’re excited about, and some of the contributions we made. If like us, you want to carry on (or start) building on PostgreSQL, give Timescale a try. Features like hypertables (automatically partitioned PostgreSQL tables), continuous aggregates (automatically refreshed materialized views), and advanced data management techniques will significantly enhance PostgreSQL's ability to manage your most demanding workloads effectively.

If you want to expand PostgreSQL’s capabilities while using the PostgreSQL you know and love, create a free Timescale account today.

Founded in 2009 in Linköping, Edeva is a Swedish company that creates powerful solutions for smart cities. It offers managed services and complete systems, including hardware and software platforms.

As the creators of the dynamic speed bump Actibump and the smart city platform EdevaLive, the Edeva team works mainly for municipal, regional, and national road administrations, toll stations, environmental agencies, and law enforcement agencies.

The team also solves many other problems, from obtaining large amounts of environmental data for decision-making to developing a screening scale to help law enforcement agencies assess vehicle overloading. The latter, for instance, decreased the amount of time needed to control each vehicle, speeding up traffic checks and allowing law enforcement agencies to control more vehicles.

About the Team

The team at Edeva is a small but impactful group of 11, working on everything from creating hardware IoT devices to analyzing time-series data and making it accessible to customers—and, sometimes, the public.

As a software architect, I am in charge of building the best possible solution to receive, store, analyze, visualize, and share the customers’ event data. Our team then comes together to create solutions that work and that the customer actually wants.

About the Project

Edeva has created a dynamic speed bump called Actibump and the smart city platform EdevaLive.

The Actibump has been used in Sweden since 2010. Speeding vehicles activate a hatch in the road that lowers a few centimeters, creating an inverted speed bump. Providing good accessibility for public transportation, such as buses and emergency vehicles, the Actibump still ensures a safe speed for pedestrians and other vulnerable road users. It is also an environmentally friendly solution, helping decrease noise and emissions.

The Actibump can be combined with the EdevaLive system, delivering valuable remote monitoring services and statistics to Edeva’s customers.

Most of the data we collect is based on IoT devices:

Traffic flow data: The Actibump measures the speed of oncoming traffic to decide if it needs to activate the speed bump or not. We capture radar data, among others, and send an event to our smart city platform EdevaLive. The data treats the oncoming traffic as a flow rather than a single vehicle to create the smoothest possible traffic flow.

Vehicle classification data (weigh-in-motion): Actibump can be configured with weigh-in-motion. This means that the lid of the speed bump is equipped with a very sensitive high-sampling scale. The scale records several weight measurements when the vehicle passes over the speed bump. This way, it can detect how many axles a vehicle has and classify the type of vehicle. At the same time, it fires off one event for each axle with the scale fingerprint so we can analyze whether the weight measurements are correct.

Vehicle classification data (radar): If we want to classify vehicles in places where we do not yet have an Actibump installed, we can introduce a radar that can classify vehicle types. A roadside server controls the radar, gathers its data, and pushes it to EdevaLive.

Bike and pedestrian data: We use cameras installed above a pedestrian and cycle path. The camera can detect and count pedestrians and bicycles passing in both directions. We push this data to EdevaLive for analysis.

Number plate data: We can use a camera to detect a vehicle's number plate. This way, we can control devices like gates to open automatically. The camera can also be used to look up the number of electric vs. petrol or diesel vehicles passing it or determine if a specific vehicle exceeds the cargo weight limit.

Gyroscopic data: We offer a gyroscopic sensor that can gather data for acceleration in all different planes. This device generates a lot of data that can be uploaded to EdevaLive in batches or as a stream (if the vehicle has an Internet connection). This data is GPS-tagged and can be used to calculate jerk to provide indications on working conditions to a bus driver, for instance. The data can also be used to calculate the wear and tear of vehicles and many other things.

Environmental data: Monitoring environmental data in a smart city platform is important. This is why we use small portable devices that can measure the occurrence of different particle sizes in the air, CO2, and other gases. In addition, they measure the usual things like temperature, wind speed, etc. All this data is pushed to EdevaLive.

Alarm data: Our IoT devices and roadside servers can send alarm information if a sensor or other parts malfunction. All this data comes to EdevaLive in the same way as a regular IoT event, but these events are only used internally so that we can react as quickly as possible if there is a problem.

Status data: If the alarm data detects anomalies, the status data just reports the status of the server or IoT device. The devices run self-checks and report statistical data, like disk utilization, temperature, and load. This is also just for internal use to spot trends or troubleshoot in case any problems arise. For instance, it is incredibly useful to correlate CPU load with the version number of firmware or other software versions.

Administrative data: This is where the power of SQL and time-series data really shines. Let’s say we added a new device, and it has a configuration object that is persistent in a regular table in Timescale. This object keeps some metadata, such as the date it was added to the system or the device's display name. This way, we can use a join easily to pick up metadata about the device and, at the same time, get time-series data for the events that are coming in. There is only one database connection to handle and one query to run.

Choosing (and Using!) TimescaleDB

We realized we needed a time-series database a few years ago when we started storing our data in MySQL. At the time, we made a move to MongoDB, and it worked well for us but required quite a bit of administration and was harder to onboard other developers.

I looked at InfluxDB but never considered it in the end because it was yet another system to learn, and we had learned that lesson with MongoDB.

Learning from this journey, I looked for a solution that plugged the gaps the previous systems couldn’t. That is when I found Timescale and discovered that there was a hosted solution.

We are a small team that creates software with a big impact. This means that we don’t really have time to put a lot of effort into tweaking and administering every tool we use, but we still like to have control.

"With Timescale, our developers immediately knew how to use the product because most of them already knew SQL"

Also, since TimescaleDB is basically PostgreSQL with time-series functionality on steroids, it is much easier to onboard new developers if needed. With Timescale, our developers immediately knew how to use the product because most of them already knew SQL.

Edeva uses TimescaleDB as the main database in our smart city system. Our clients can control their IoT devices (like the Actibump from EdevaLive) and—as part of that system—see the data that has been captured and quickly get an overview of trends and historical data. We offer many graphs that show data in different time spans, like day, week, month, and year. To get this to render really fast, we use continuous aggregations.

"Timescale is basically PostgreSQL with time-series functionality on steroids, it is much easier to onboard new developers if needed"

Current Deployment and Future Plans

One of the TimescaleDB features that has had the most impact on our work is continuous aggregations. It changed our dashboards from sluggish to lightning-fast. If we are building functionality to make data available for customers, we always aggregate it first to speed up the queries and take the load off the database. It used to take minutes to run some long-term data queries. Now, almost all queries for long-term data are subsecond.

"We rely on Timescale for everything now. It's super efficient, and we've reduced query load times from 30 seconds down to almost nothing." - John Eskilsson, System Architect

For example, we always struggled with showing the 85th percentile of speed over time. To get accurate percentile data, you had to calculate it based on the raw data instead of aggregating it. If you had 200 million events in a hypertable and wanted several years of data for a specific sensor, it could take you a long time to deliver—users don’t want to wait that long.

"It changed our dashboards from sluggish to lightning-fast"

Now that Timescale introduced percentile_agg and approx_percentile, we can actually query continuous aggregations and get reasonably accurate percentile values without querying raw data.

Note that “vehicles” is a hypertable where actibump_id is the ID of the dynamic speed bump containing several hundred million records.

This is how we build the continuous aggregate:

CREATE MATERIALIZED VIEW view1
 WITH (timescaledb.continuous) AS
 SELECT actibump_id,
 timescaledb_experimental.time_bucket_ng(INTERVAL '1 month', time, 'UTC') AS bucket,
 percentile_agg(vehicle_speed_initial) AS percentile_agg
FROM vehicles
GROUP BY actibump_id, bucket

And this is the query that fetches the data for the graph:

SELECT TIMESCALEDB_EXPERIMENTAL.TIME_BUCKET_NG(INTERVAL '1 month', bucket) AS date,
actibump_id,
APPROX_PERCENTILE(0.85, ROLLUP(PERCENTILE_AGG)) AS p85,
MAX(signpost_speed_max)
FROM vehicles_summary_1_month
WHERE actibump_id in ('16060022')
AND bucket >= '2021-01-30 23:00:00'
AND bucket <= '2022-04-08 21:59:59'
GROUP BY date, actibump_id
ORDER BY date ASC

Here is an example of the graph:

At the moment, we use PHP and Yii 2 to deploy TimescaleDB. We connect to TimescaleDB with Qlik Sense for business analytics. In Qlik Sense, you can easily connect to TimescaleDB using the PostgreSQL integration.

It is especially convenient to be able to connect to the continuous aggregations for long-term data without overloading the system with too much raw data. We often use Qlik Sense to rapidly prototype graphs that we later add to EdevaLive.

Advice and Resources

The next step for us is to come up with a good way of reducing the amount of raw data we store in TimescaleDB. We are looking at how we can integrate it with a data lake. Apart from that, we are really excited to start building even more graphs and map applications.

If you are planning to store time-series data, Timescale is the way to go. It makes it easy to get started because it is “just” SQL, and at the same time, you get the important features needed to work with time-series data. I recommend you have a look, especially at continuous aggregations.

Think about the whole lifecycle when you start. Will your use cases allow you to use features like compression, or do you need to think about how to store long-term data outside of TimescaleDB to make it affordable right from the start? You can always work around things as you go along, but it is good to have a plan for this before you go live.

We’d like to thank John and all the folks from Edeva for sharing their story. We are amazed to see how their work truly impacts the way people live and enjoy their city with a little help from time-series data. 🙌

We’re always keen to feature new community projects and stories on our blog. If you have a story or project you’d like to share, reach out on Slack (@Ana Tavares), and we’ll go from there.