How to Safely Perform Backfill Operations in TimescaleDB

Backfilling data into a TimescaleDB hypertable in production can be very tricky, especially when automated processes like compression policies are involved. From past experience, we have seen that if backfill operations aren’t handled properly, they can interfere with these automated tasks, sometimes causing them to stop working altogether.  This blog covers a safer and more reliable approach to backfilling hypertables, along with best practices to prevent disruptions to compression and other background processes. What is a Backfill Operation? Backfilling means adding old or missing data into the database table after some time has already passed.  Imagine you are collecting temperature readings every hour, but your system was down for a day and didn’t save any data. Later, you get that missing data from the local storage of the device or cloud storage, and want to put it back in the right hypertable, which is called backfilling.  In TimescaleDB, this is common with time-series data, but it needs to be done carefully. That’s because TimescaleDB might already be doing things in the background, like compressing old data to save space. If we are not careful, backfilling can mess up these automatic tasks.
Read More

Step by Step Guide on Setting Up Physical Streaming Replication in PostgreSQL

Physical streaming replication in PostgreSQL allows you to maintain a live copy of your database on a standby server, which continuously receives updates from the primary server’s WAL (Write-Ahead Log). This standby (or hot standby) can handle read-only queries and be quickly promoted to primary in case of failover, providing high availability and disaster recovery. In this guide, I will walk through provisioning a primary PostgreSQL 16 server and a standby server on Linux, configuring them for streaming replication, and verifying that everything works. I assume you are an experienced engineer familiar with Linux, but new to PostgreSQL replication, so I will keep it friendly and straightforward. Figure: Real-time data streaming from a primary PostgreSQL server (left) to a standby server (right). The standby constantly applies WAL records received from the primary over a network connection, keeping an up-to-date copy of the database ready for failover. Step 1: Prepare Two Linux Servers and Install PostgreSQL 16 Before diving into PostgreSQL settings, set up two Linux servers (virtual or physical). One will act as the primary database server, and the other as the standby (read replica). For a smooth replication setup, both servers should be as similar as possible in OS, hardware, and PostgreSQL version. In particular, ensure the following prerequisites: PostgreSQL 16 is installed on both servers via the official PostgreSQL repositories. Both servers must run the same major PostgreSQL version and architecture (mixing different versions won’t work for physical replication). If you haven’t installed PostgreSQL yet, do so now (e.g., on Ubuntu: sudo apt install postgresql-16, or on RHEL/CentOS: use the PostgreSQL Yum repository). Make sure the PostgreSQL service is running on the primary server. Network connectivity: The standby must be able to reach the primary on the PostgreSQL port (default 5432). If the servers are in a cloud environment like AWS EC2, configure the security group or firewall to allow the standby’s IP to connect to the primary on port 5432. For example, in AWS you’d add an inbound rule permitting the standby’s private IP address (or subnet) access to port 5432 on the primary. It is best to use private network interfaces for replication to reduce latency and avoid exposing the database publicly. System settings: Ensure your servers have the necessary OS user and permissions for PostgreSQL. The installation usually creates a postgres UNIX user that owns the data directories. You will run many commands as this postgres user. Also, verify that important prerequisites like consistent time sync (NTP) are in place, as it is generally good practice for database servers (though not specific to replication). With the infrastructure ready, let’s proceed to configure the primary PostgreSQL server to accept replication connections.
Read More

Improving PostgreSQL Performance with Partitioning

My recommended methodology for performance improvement of PostgreSQL starts with query optimization. The second step is architectural improvements, part of which is the partitioning of large tables. Partitioning in PostgreSQL is one of those advanced features that can be a powerful performance booster. If your PostgreSQL tables are becoming very large and sluggish, partitioning might be the cure. The Big Table Problem Large tables tend to grow uncontrollably, especially in OLTP or time-series workloads. As millions or billions of rows accumulate, you begin to notice: Slow queries due to full table scans or massive indexes. Heavy I/O usage, especially when indexes cannot fit in memory. Bloated memory during operations like sorting or joining. Increased maintenance cost, with longer VACUUM, ANALYZE, and REINDEX times. Hard-to-manage retention policies, as purging old rows becomes expensive. These problems are amplified in cloud-hosted databases, where every IOPS, GB, or CPU upgrade increases cost.
Read More

Finding Bottlenecks and Avoiding Over-Optimization via Explain Plans

Performance optimization in a production database is important, but trying to over-optimize can make things more complicated without real improvements. In this post, I’ll share two very basic EXPLAIN ANALYZE outputs from a production system. A user asked us to help optimize these queries. I've changed the table and column names for privacy. We will look at how to spot slow parts of a query, improve performance the right way, and avoid unnecessary tuning. Plan A: Identifying and Resolving a Bottleneck Execution Plan A (Before Optimization) Nested Loop (cost=1000.42..25607.38 rows=1 width=129) (actual time=78.521..90.445 rows=0 loops=1) -> Gather (cost=1000.00..25598.95 rows=1 width=65) (actual time=78.520..90.443 rows=0 loops=1) Workers Planned: 2 Workers Launched: 2 -> Parallel Seq Scan on <table_1> e (cost=0.00..24598.85 rows=1 width=65) (actual time=75.351..75.351 rows=0 loops=3) Filter: ((<column_1>) = '<date_value>'::date) AND ((<column_2>)::text = '<event_type>'::text) Rows Removed by Filter: <number_removed_rows> -> Index Scan using <index_name> on <table_2> a (cost=0.42..8.43 rows=1 width=41) (never executed) Index Cond: ((<column_3>)::text = (<column_4>)::text) Filter: ((<column_5>)::text = '<default_value>'::text) Planning Time: 0.466 ms Execution Time: 90.580 ms
Read More

SELECT FOR UPDATE – Reduce Contention and Avoid Deadlocks to Improve Performance in PostgreSQL

Relational databases are at the heart of countless applications around the world, from high-traffic e-commerce websites to enterprise resource planning (ERP) systems and financial services. Concurrency management—where multiple database transactions operate on the same data simultaneously—is critical to getting good performance and avoiding problems like deadlocks or data inconsistencies. When multiple transactions need to modify the same rows, ensuring data consistency can become tricky. A single wrong approach to locking can lead to suboptimal performance or even bring your application to a standstill as numerous transactions block one another. One tool in PostgreSQL’s arsenal to handle concurrency is SELECT FOR UPDATE. It allows you to lock specific rows before updating them, preventing other transactions from modifying those rows until your transaction completes. In this blog, we will dive deep into SELECT FOR UPDATE in PostgreSQL. We will explore how it helps in reducing contention, avoiding deadlocks, and ultimately boosting performance when dealing with highly concurrent applications.
Read More

When HASH partitioning works better than RANGE

I have always been a fan of RANGE partitioning using a date/time value in PostgreSQL. This isn't always possible, however, and I recently came across a scenario where a table had grown large enough that it had to be partitioned, and the only reasonable key to use was a UUID styled identifier. The goal of this post is to highlight when and why hashing your data across partitions in PostgreSQL might be a better approach. Range vs. Hash Partitioning in PostgreSQL Range Partitioning (A Quick Recap) Range partitioning in PostgreSQL uses boundary values that define slices of the data, often by date or numeric ranges. If you have a transactions table, you might create monthly partitions based on a transaction_date column. This is intuitive for time-series data because each partition holds rows from a specific date range. Advantages of Range Partitioning: Easy pruning for date-based queries. Straightforward approach to archiving old data: drop an entire partition for a past month, rather than issuing a massive DELETE. Pairs nicely with time-based ingestion pipelines, where every day or month gets its own partition. But as convenient as that is, there are cases where range partitioning runs into problems. Why Range Partitioning Can Fall Short Data Skew: If a huge portion of data lands in a single time interval—say, because of a traffic spike in the current month—that monthly partition might end up significantly larger than the others. Complex Backfills: Not everyone ingests data in an orderly, daily manner. Sometimes you need to re-ingest or correct data that spans multiple periods. Merging or splitting range partitions can get cumbersome. Non-Date Dimensions: Some tables aren’t naturally tied to a sequential numeric or date dimension. If your queries center on user IDs or device IDs, dividing by date might not solve your performance issues.
Read More

Important PostgreSQL Parameters: Understanding Their Importance and Recommended Values

Have you ever experienced your database slowing down as the amount of data increases? If so, one important factor to consider is tuning PostgreSQL parameters to match your specific workload and requirements.  PostgreSQL has many parameters because it is designed to be highly flexible and customizable to meet a wide range of use cases and workloads. Each parameter allows you to fine-tune different aspects of the database, such as memory management, query optimization, connection handling, and more. This flexibility helps database administrators to optimize performance based on hardware resources, workload requirements, and specific business needs. In this blog, I will cover some of the important PostgreSQL parameters, explain their role, and provide recommended values to help you fine-tune your database for better performance and scalability.  Memory-Related Parameters Memory-related parameters in PostgreSQL control how the database allocates and manages memory. Tuning these settings is important for improving query performance and preventing resource bottlenecks. Name: work_mem Description: Sets the maximum amount of memory used by internal operations like sorts and hashes before writing to disk. Increasing it can improve performance for complex queries Default: 4MB Recommended: Typically, setting work_mem to 1-2% of the total system's available memory is recommended, i.e., if the total system memory is 256 GB, assign 3 to 5 GB for work_mem. Note: This may lead to higher memory usage for operations that involve sorting. Name: shared_buffers Description: Determines the amount of memory allocated for caching database data. Default: 128MB Recommendation: Typically, setting shared_buffers to 25-40% of the total system memory is recommended, i.e., if the total system memory is 256 GB, assign 64-102 GB for shared_buffers. Name: maintenance_work_mem Description: Specifies the amount of memory used for maintenance operations like VACUUM, CREATE INDEX, and ALTER TABLE. Increasing it can speed up these operations. Default: 64MB Recommendation: it's recommended to set 5-10% of the total system memory, i.e., if the total system memory is 256 GB, assign 13 to 26 GB for maintenance_work_mem.
Read More

A Guide to Restoring a PostgreSQL Database from Disaster Using Azure Flexible Server

Backups are crucial for any mission-critical application as they protect against unforeseen disasters. Regular backups help minimize the Recovery Point Objective (RPO), allowing systems to recover quickly with minimal data loss. However, it's equally important to store backups safely. If backups are kept in the same location as the primary site and something goes wrong, you may have no way to recover, leading to complete data loss. To reduce these risks, many organizations choose fully managed servers to host their databases. One popular option is Azure Flexible Server for PostgreSQL, which offers a reliable, scalable, and managed solution.  Azure provides 3 levels of redundancy in three different ways, and not only that, you can recover backups using these same three methods. These are Locally Redundant Storage Zone Redundant Storage Geo Redundant Each level of redundancy offers unique advantages when it comes to restoring backups. In today's blog, we will explore all three types of backups and recovery methods. We will dive into the differences between each type and learn how to restore your backup if your primary site goes down.
Read More

Leveraging autovacuum in PostgreSQL to optimize performance and reduce costs

Autovacuum is one of PostgreSQL's most powerful features, designed to maintain database health and optimize performance by automating routine maintenance tasks. However, improper configuration can lead to performance bottlenecks, excessive costs due to resource inefficiency, or uncontrolled table bloat. This blog explores what autovacuum is, its role in performance optimization and cost reduction, and best practices for configuring its parameters. What is Autovacuum? Autovacuum is a background process in PostgreSQL responsible for maintaining table health by performing two critical tasks: 1. Vacuuming - Removes dead tuples (rows that have been updated or deleted but are no longer visible). - Frees up space for reuse to prevent table bloat and reduce storage costs. 2. Analyzing - Updates table statistics used by the query planner to optimize execution plans, improving query performance. Without autovacuum, dead tuples can accumulate, leading to: - Table Bloat: Increased disk usage drives up storage costs and slows query performance. - Transaction ID Wraparound: A situation that forces the system to go into ‘safe mode’, blocking non-superuser transactions to protect data integrity. This can render the database unusable if not addressed, causing downtime and increased operational costs. By automating these tasks, autovacuum ensures consistent database performance and minimizes unnecessary costs.
Read More

Archives

Categories