Add postgresql-dba content

src/data/roadmaps/postgresql-dba/content/100-roadmap-note.md

@@ -1 +1,7 @@
-# Roadmap note
+# Important Note
+
+This roadmap is designed to help you learn the basics of PostgreSQL database administration. It is not intended to be a comprehensive guide to PostgreSQL administration, but rather a starting point for your journey. It is recommended that you supplement this roadmap with additional resources, hands-on practice, and community engagement to best enhance your understanding and skills in PostgreSQL administration.
+
+This roadmap note is designed to guide you through these crucial topics, helping you gain competency in PostgreSQL database administration.
+
+Keep in mind that this guide serves as an outline, and it is recommended to supplement it with additional resources, hands-on practice, and community engagement to best enhance your understanding and skills in PostgreSQL administration. Remember that learning is an ongoing process, and be prepared to adapt to new developments and updates within the PostgreSQL ecosystem.

src/data/roadmaps/postgresql-dba/content/101-introduction/100-what-are-relational-databases.md

@@ -1 +1,43 @@
-# What are relational databases
+# What are Relational Databases?
+
+# What are Relational Databases?
+
+Relational databases are a type of database management system (DBMS) that store structured data in tables. This type of database organization allows users to efficiently access, manipulate, and search for data within the system. The term "relational" refers to the manner in which the data is stored – as a collection of related tables.
+
+### Structure of Relational Databases
+
+The main building blocks of any relational database are:
+
+1. **Tables**: Each table represents a specific entity or object and is organized into rows and columns. Rows (also known as records or tuples) represent individual instances of the entity, while columns (also known as fields or attributes) represent attributes or properties of each instance.
+
+2. **Keys**: To uniquely identify and relate tables, relational databases use a combination of primary keys and foreign keys. A primary key is a unique identifier within a table, while a foreign key is a field in one table that refers to the primary key of another table.
+
+3. **Schema**: The schema is the blueprint or structure of the database. It defines how the tables, keys, and relationships between tables are organized.
+
+### Basic Operations in Relational Databases
+
+The basic operations that can be performed in relational databases include:
+
+1. **Create**: This is the process of defining the structure and characteristics of a new table or object within the database.
+
+2. **Query**: Querying is the operation of retrieving specific data from the tables in the database, typically using SQL (Structured Query Language). SQL allows users to retrieve, filter, sort, and manipulate data based on specific criteria.
+
+3. **Update**: Updating involves modifying the data stored in the database, such as adding new records, changing values, or deleting records.
+
+4. **Delete**: This operation allows users to remove specific records from the database.
+
+### Key Advantages of Relational Databases
+
+Some of the most notable advantages of using relational databases include:
+
+1. **Structured data organization**: The row and column organization allows for easy retrieval of specific data based on specified criteria.
+
+2. **Data consistency**: The use of primary and foreign keys enforces relationships between tables, ensuring data integrity.
+
+3. **Flexibility**: Relational databases allow users to create complex queries and report structures, which are essential for data extraction and analysis.
+
+4. **Scalability**: They can handle large amounts of data and can be expanded to meet the growing needs of an organization.
+
+5. **Security**: Relational databases provide a wide range of security features to ensure that sensitive data is protected and only accessible by authorized users.
+
+In summary, relational databases provide a powerful and flexible way to store and manage structured data. Throughout this guide, we will further explore PostgreSQL, an advanced open-source relational database management system, and dive into the best practices for efficient database administration.

src/data/roadmaps/postgresql-dba/content/101-introduction/101-rdbms-benefits-limitations.md

@@ -1 +1,29 @@
-# Rdbms benefits limitations
+# RDBMS Benefits and Limitations
+
+## RDBMS Benefits and Limitations
+
+In this section, we will discuss some of the key benefits and limitations of using a Relational Database Management System (RDBMS) like PostgreSQL.
+
+### Benefits of RDBMS
+
+1. **Data Consistency:** One of the main advantages of using an RDBMS is that it ensures data consistency by enforcing referential integrity, entity integrity, and domain constraints. This helps maintain data accuracy and prevent anomalies.
+
+2. **Easier Data Management:** RDBMS provides an easy-to-use interface for structured data storage, retrieval, and manipulation using SQL (Structured Query Language). SQL enables users to perform complex data operations with simple queries.
+
+3. **Data Security:** RDBMS offers several layers of data security, including user authentication, authorization, and encryption. These features help protect sensitive data from unauthorized access and maintain data privacy.
+
+4. **Scalability and Performance:** Modern RDBMSs like PostgreSQL are designed to be highly scalable, allowing them to handle large amounts of data and a growing number of users. Efficient indexing and query optimization techniques also contribute to better performance.
+
+5. **ACID Transactions:** RDBMS supports ACID (Atomicity, Consistency, Isolation, and Durability) properties for transactions, ensuring the reliability of data processing.
+
+### Limitations of RDBMS
+
+1. **Handling Unstructured Data:** RDBMS is designed for structured data, and handling unstructured or semi-structured data (like JSON, images, or text documents) can be challenging. Though PostgreSQL supports JSON and some other data types, NoSQL databases might be better suited for such data.
+
+2. **Scalability Limitations:** While RDBMS can be scaled vertically by adding more resources to the same server, horizontal scaling (adding more servers) can be complex and may require partitioning/sharding, impacting data consistency or introducing additional management overhead.
+
+3. **Complexity:** RDBMS can be complex to set up, maintain, and optimize, requiring skilled and experienced database administrators (DBAs) to manage the system effectively.
+
+4. **Cost:** Licensing, hardware, and maintenance costs for RDBMS can be high, especially for enterprise-grade solutions. There are open-source alternatives like PostgreSQL, but they might require more initial setup and configuration.
+
+By understanding the benefits and limitations of RDBMS, you can make an informed decision about whether it is the right choice for your organization's data management needs. In the next sections, we will dive deeper into PostgreSQL, a popular open-source RDBMS, and its features, installation, and administration tasks.

src/data/roadmaps/postgresql-dba/content/101-introduction/102-postgresql-vs-others.md

@@ -1 +1,31 @@
-# Postgresql vs others
+# PostgreSQL vs Other RDBMS
+
+# PostgreSQL vs Other Databases
+
+In this section, we will compare PostgreSQL to other popular databases, such as MySQL, SQLite, and MongoDB. Understanding the differences and similarities between these databases will help you make a more informed decision when choosing a database for your projects.
+
+## PostgreSQL vs MySQL
+
+- **ACID Compliance**: Both PostgreSQL and MySQL are ACID-compliant, ensuring reliable and consistent transactions.
+- **Performance**: MySQL is known for its high read/write speeds, which makes it suitable for read-heavy applications. PostgreSQL is known for its overall robustness and flexibility, which makes it a better choice for write-heavy and complex applications.
+- **Concurrency**: PostgreSQL uses Multi-Version Concurrency Control (MVCC), while MySQL uses table-level and row-level locking.
+- **Extensions**: PostgreSQL has a more extensive support for extensions, such as PostGIS for geospatial data or HStore for key-value data storage.
+- **License**: MySQL is developed under an open-source GPLv2 license, while PostgreSQL is developed under an open-source PostgreSQL License.
+
+## PostgreSQL vs SQLite
+
+- **Use case**: PostgreSQL is a powerful, enterprise-class database suitable for large-scale applications, while SQLite is an embedded database suitable for smaller applications, such as mobile apps and small desktop applications.
+- **Concurrency**: PostgreSQL supports multiple concurrent users, while SQLite is limited to a single user (typically the application) accessing the database at any given time.
+- **Scalability**: PostgreSQL is designed to be scalable, supporting a significant number of concurrent connections and large datasets. SQLite is best suited for small applications with limited data.
+- **ACID Compliance**: Both PostgreSQL and SQLite are ACID-compliant, ensuring reliable transactions.
+
+## PostgreSQL vs MongoDB
+
+- **Database Type**: PostgreSQL is a mature, ACID-compliant relational database, while MongoDB is a relatively new, highly scalable NoSQL database.
+- **Data Model**: PostgreSQL uses tables, rows, and columns to store data, while MongoDB uses flexible JSON-like documents (BSON) for data storage.
+- **Query Language**: PostgreSQL uses the standard SQL language for querying and managing data, while MongoDB uses its own query language, MQL (MongoDB Query Language).
+- **Consistency vs Availability**: PostgreSQL prioritizes data consistency, ensuring data accuracy and strong consistency. MongoDB prioritizes high availability and partition tolerance, with eventual consistency.
+
+In summary, each of these databases has its strengths and weaknesses, depending on the specific use cases and requirements of your applications. If you require a flexible and highly scalable database with high availability, MongoDB might be a better choice. If you need a highly consistent, reliable, and feature-rich relational database, PostgreSQL is a strong contender. For small applications with limited user access and data, SQLite can be an efficient and straightforward choice.
+
+Ultimately, understanding the specific needs of your project and the capabilities of each database will help you make the best decision for your application.

src/data/roadmaps/postgresql-dba/content/101-introduction/103-postgresql-vs-nosql.md

@@ -1 +1,62 @@
-# Postgresql vs nosql
+# PostgreSQL vs NoSQL Databases
+
+# PostgreSQL vs NoSQL
+
+In this section, we will discuss the differences between PostgreSQL and NoSQL databases, highlighting their unique features, advantages, and disadvantages, which will help you in making an informed decision about which database system to use for your projects.
+
+## Overview
+
+PostgreSQL is a powerful, open-source object-relational database management system (ORDBMS) that emphasizes extensibility and SQL compliance. It is a popular choice for managing structured data.
+
+On the other hand, NoSQL (Not Only SQL) databases are a class of non-relational databases specifically designed to manage unstructured or semi-structured data, such as social media posts, multimedia content, and sensor data. Examples of popular NoSQL databases include MongoDB, Cassandra, Couchbase, and Redis.
+
+### Features
+
+#### PostgreSQL 
+
+1. **ACID Compliance**: PostgreSQL is ACID-compliant, ensuring that all transactions are reliable, consistent, and follow the properties of Atomicity, Consistency, Isolation, and Durability.
+2. **SQL Support**: PostgreSQL supports complex queries and data manipulation operations using SQL, which is a well-known and widely used query language.
+3. **Extensibility**: PostgreSQL's extensibility allows users to create custom functions, operators, and data types, tailoring the database system to their specific needs.
+4. **Concurrency Control**: PostgreSQL uses a multiversion concurrency control (MVCC) mechanism to handle multiple users' concurrent access to the database without conflicts.
+
+#### NoSQL
+
+1. **Schema-less**: NoSQL databases don't require a predefined schema, making them well-suited to manage unstructured data that doesn't fit into a traditional table structure.
+2. **Scalability**: NoSQL databases are designed to scale out by distributing data across multiple nodes, making them appropriate for managing large-scale, high-traffic applications.
+3. **Flexibility**: As the data structure is not fixed in NoSQL databases, they provide greater flexibility to modify the data model without impacting the application's performance.
+4. **High Performance**: The simpler data model and lack of complex join operations in NoSQL databases make them faster and more efficient for specific use cases.
+
+## Advantages & Disadvantages
+
+### PostgreSQL
+
+#### Advantages
+
+1. Reliable and stable with a long history of development and active community support.
+2. Rich set of features and extensive SQL support for complex query operations.
+3. Ideal for managing structured data in a relational model, such as transactional data and inventory management systems.
+
+#### Disadvantages
+
+1. Horizontal scalability and sharding can be a challenge in comparison to NoSQL databases.
+2. Not particularly suited for managing large-scale, unstructured data.
+
+### NoSQL
+
+#### Advantages
+
+1. Handles large volumes of unstructured or semi-structured data efficiently.
+2. Highly scalable and can distribute data across multiple nodes with ease.
+3. Offers high performance for specific use cases, such as real-time analytics and web-based applications.
+
+#### Disadvantages
+
+1. Not as mature as PostgreSQL, which might result in fewer features, tools, and community support.
+2. The lack of standardized query language for NoSQL databases might impose a steep learning curve.
+3. Not suitable for applications that require complex transactions or data integrity guarantees.
+
+## Conclusion
+
+Choosing between PostgreSQL and NoSQL databases depends on your specific use case and the requirements of your projects. If you need a robust and mature system for managing structured data with complex queries and strong consistency guarantees, PostgreSQL is an excellent choice.
+
+On the other hand, if you need a flexible and scalable system for managing unstructured or semi-structured data, with high read/write performance, a NoSQL database could be more suitable. Evaluate the needs of your application and make an informed decision based on the features, advantages, and disadvantages outlined in this section.

src/data/roadmaps/postgresql-dba/content/101-introduction/index.md

@@ -1 +1,48 @@
-# Introduction
+# Introduction
+
+# Introduction to PostgreSQL DBA
+
+Welcome to this guide on PostgreSQL DBA (Database Administrator)! In this introduction, we will provide you with an overview of what to expect from this guide, the importance of a PostgreSQL DBA, and the key concepts you will learn.
+
+PostgreSQL is a powerful, enterprise-level, open-source relational database management system (RDBMS) that emphasizes extensibility and SQL compliance. As organizations increasingly rely on data-driven decision-making, effective management of database systems becomes crucial. That's where the role of a PostgreSQL DBA comes in.
+
+## What to Expect From This Guide?
+
+This guide is designed to help you understand and acquire the necessary skills for managing and maintaining a PostgreSQL database system. We will cover essential concepts, best practices, and practical examples that you can apply to real-world scenarios in your organization.
+
+Some of the topics that we will cover in this guide are:
+
+- PostgreSQL Architecture
+- Installation and Configuration
+- Database Management (creating, altering, and deleting databases and tables)
+- Backup and Recovery
+- Performance Tuning
+- Security and Access Control
+- Monitoring and Maintenance
+- Replication and High Availability
+
+## Importance of a PostgreSQL DBA
+
+A PostgreSQL DBA is responsible for managing and maintaining the health, performance, and security of database systems. They ensure that data is stored and organized efficiently, and can be easily accessed or modified by applications and users when needed.
+
+As a PostgreSQL DBA, you will:
+
+- Protect the integrity and consistency of your organization's data
+- Ensure optimal performance and quick response times for database queries
+- Safeguard sensitive data through proper access control measures
+- Plan for future growth and scalability, minimizing downtime and disruptions
+- Troubleshoot and resolve database-related issues
+
+## Key Concepts You Will Learn
+
+Throughout this guide, we will cover several essential concepts that every PostgreSQL DBA should know:
+
+1. **Architecture**: Understand how PostgreSQL is structured and how different components interact with each other.
+2. **SQL**: Familiarize yourself with SQL commands and learn how to use them to manage and manipulate data.
+3. **Backup, Recovery, and Disaster Management**: Learn how to create backups, restore data, and plan for possible disasters.
+4. **Performance Tuning**: Discover techniques to optimize the performance of your PostgreSQL database.
+5. **Security**: Implement best practices to secure your PostgreSQL database and ensure proper access control.
+6. **Monitoring and Maintenance**: Learn about tools and strategies to monitor the health of your PostgreSQL database and perform routine maintenance tasks.
+7. **Replication and High Availability**: Understand how to set up replication and achieve high availability for your PostgreSQL database.
+
+We hope this introduction has given you an idea of what to expect from this guide. As you progress through the guide, you will build the skills and knowledge required to become a proficient PostgreSQL DBA. So, let's dive in and get started on this exciting journey!

src/data/roadmaps/postgresql-dba/content/102-rdbms-concepts/100-object-model/100-databases.md

@@ -1 +1,83 @@
-# Databases
+# Databases
+
+# Databases in PostgreSQL
+
+In this section, we will discuss the significance and functionality of databases in PostgreSQL, as well as provide some examples for creating, managing, and connecting to databases.
+
+## Overview
+
+A *database* in PostgreSQL is a collection of related data, consisting of tables, indexes, functions, views, and other objects. PostgreSQL uses a client-server model, and a database is where all the client connections and transactions occur. PostgreSQL supports multiple databases within a single database cluster, which assures data isolation and convenient management of different applications within the same server instance.
+
+## Creating a Database
+
+To create a database, use the command `CREATE DATABASE` followed by the name of the database:
+
+```sql
+CREATE DATABASE database_name;
+```
+
+For example, to create a database named "mydb":
+
+```sql
+CREATE DATABASE mydb;
+```
+
+You can also specify additional options, such as the owner of the database, the encoding and collation, and more:
+
+```sql
+CREATE DATABASE database_name
+OWNER username
+ENCODING 'encoding_name'
+LC_COLLATE 'collation_name'
+LC_CTYPE 'ctype_name'
+TEMPLATE template_name
+TABLESPACE tablespace_name;
+```
+
+## Listing Databases
+
+To see a list of all databases in your PostgreSQL instance, use the `\l` command in the `psql` command prompt:
+
+```
+\l
+```
+
+You will see a list of databases with their names, owners, characters set encoding, collation, and other details.
+
+## Connecting to a Database
+
+To connect to a specific database, use the `\c` or `\connect` command in `psql`, followed by the database name:
+
+```
+\c database_name
+```
+
+Alternatively, you can connect to a database from the command line when starting `psql`:
+
+```
+psql -h hostname -p port -U username -d database_name
+```
+
+## Managing Databases
+
+You can modify the properties of an existing database with the `ALTER DATABASE` command:
+
+```sql
+ALTER DATABASE database_name
+[OWNER TO new_owner]
+[SET configuration_parameter { TO | = } { value | DEFAULT }]
+[RESET configuration_parameter]
+[WITH new_options];
+```
+
+To drop a database, use the `DROP DATABASE` command:
+
+```sql
+DROP DATABASE database_name;
+```
+
+**Caution: Dropping a database will permanently delete all data and objects contained within it.**
+
+## Conclusion
+
+Understanding databases in PostgreSQL is crucial for managing and organizing your data. In this section, we discussed the basics of creating, listing, connecting to, and managing databases in PostgreSQL. As a DBA, you will need to be familiar with these concepts to ensure proper data management and isolation for various applications within your PostgreSQL instance.

src/data/roadmaps/postgresql-dba/content/102-rdbms-concepts/100-object-model/101-tables.md

@@ -1 +1,95 @@
-# Tables
+# Tables
+
+## Tables in PostgreSQL
+
+Tables are the most essential and fundamental aspect of PostgreSQL. They are responsible for storing data in an organized manner, and they are where your schema design and queries largely take place. In this section, we'll discuss tables in more detail and highlight the principal concepts you should know as a PostgreSQL DBA.
+
+### Overview
+
+A table in PostgreSQL is characterized by its columns and rows. Columns define the types of data to be stored in the table, while rows represent the actual data being stored. Each column has a name and a data type, assigned when the table is created. Some common data types are `integer`, `text`, `numeric`, and `date`. It's crucial to choose appropriate data types for smoother performance and efficient storage.
+
+### Creating Tables
+
+To create a table, you'll use the `CREATE TABLE` command. This command requires you to provide the table name and define its columns with their data types. Optionally, you can also specify constraints on columns, such as `NOT NULL`, `UNIQUE`, and `FOREIGN KEY`. Here's an example of table creation:
+
+```sql
+CREATE TABLE customers (
+    id SERIAL PRIMARY KEY,
+    first_name VARCHAR(50) NOT NULL,
+    last_name VARCHAR(50) NOT NULL,
+    email VARCHAR(255) UNIQUE,
+    date_of_birth DATE
+);
+```
+
+This creates a `customers` table with columns as: `id`, `first_name`, `last_name`, `email`, and `date_of_birth`. The `id` column is set as a primary key, which uniquely identifies each row.
+
+### Modifying Tables
+
+Once a table is created, you may need to modify it, for example, to add, remove or alter columns. PostgreSQL provides the `ALTER TABLE` command for this purpose. 
+
+#### Add a Column
+
+To add a column to an existing table, use the `ADD COLUMN` clause as shown below:
+
+```sql
+ALTER TABLE customers ADD COLUMN phone VARCHAR(20);
+```
+
+This adds a `phone` column to the `customers` table.
+
+#### Rename a Column
+
+If you need to rename an existing column, use the `RENAME COLUMN` clause:
+
+```sql
+ALTER TABLE customers RENAME COLUMN phone TO contact_number;
+```
+
+This changes the column name from `phone` to `contact_number`.
+
+#### Alter a Column's Data Type
+
+To modify the data type of a column on an existing table, use the `ALTER COLUMN` clause:
+
+```sql
+ALTER TABLE customers ALTER COLUMN date_of_birth TYPE TIMESTAMP;
+```
+
+This changes the `date_of_birth` column's data type from `DATE` to `TIMESTAMP`.
+
+#### Drop a Column
+
+If you need to remove a column from an existing table, use the `DROP COLUMN` clause:
+
+```sql
+ALTER TABLE customers DROP COLUMN contact_number;
+```
+
+This removes the `contact_number` column from the `customers` table.
+
+### Deleting Tables
+
+When you no longer need a table, you can use the `DROP TABLE` command to delete it, as shown below:
+
+```sql
+DROP TABLE customers;
+```
+
+This completely removes the `customers` table, along with all its data.
+
+### Indexes on Tables
+
+Indexes are an essential part of PostgreSQL, as they allow you to improve query speed and efficiency by reducing the time it takes to search for data in large tables. Most commonly, indexes are created on columns, which are used as filters (e.g., `WHERE columnName = 'value'`) or as join conditions in SQL queries.
+
+To create an index on a specific column, use the `CREATE INDEX` command:
+
+```sql
+CREATE INDEX customers_email_idx ON customers (email);
+```
+
+This creates an index named `customers_email_idx` on the `email` column of the `customers` table.
+
+### Conclusion
+
+Understanding tables in PostgreSQL is crucial for any PostgreSQL DBA. They form the foundation of schema design, data storage, and query processing. As a DBA, you should be familiar with managing tables, their columns, data types, constraints, and indexes.

src/data/roadmaps/postgresql-dba/content/102-rdbms-concepts/100-object-model/102-schemas.md

@@ -1 +1,63 @@
-# Schemas
+# Schemas
+
+## Schemas in PostgreSQL
+
+In PostgreSQL, a schema is a namespace that holds a collection of database objects such as tables, views, functions, and operators. Schemas help you in organizing your database objects and managing access controls effectively.
+
+### Benefits of using schemas
+
+1. **Organization**: Schemas allow you to group database objects into logical units, making it easier for you to organize and search for objects.
+
+2. **Access control**: Schemas make it possible to set permissions at the schema level, which can be beneficial for managing access to subsets of database objects.
+
+3. **Separation**: Schemas can be used to create separate environments within a single database, which can be useful for development, testing, and production stages.
+
+4. **Schema search path**: Using a search path, you can control which schemas your queries should access without explicitly specifying the schema when referencing database objects.
+
+### Creating and managing schemas
+
+To create a new schema, you can use the `CREATE SCHEMA` command:
+
+```sql
+CREATE SCHEMA schema_name;
+```
+
+To drop a schema and all its associated objects, you can use the `DROP SCHEMA` command:
+
+```sql
+DROP SCHEMA schema_name CASCADE;
+```
+
+To view a list of all available schemas within your database, you can query the `pg_namespace` system catalog table:
+
+```sql
+SELECT nspname FROM pg_namespace;
+```
+
+### Schema search path
+
+By default, PostgreSQL has an implicit schema search path that includes the `public` schema. You can modify the search path by setting the `search_path` configuration parameter.
+
+For example, to set the search path to include both the `public` and `myschema` schemas, you can run the following command:
+
+```sql
+SET search_path TO myschema, public;
+```
+
+This command will include both schemas in the search path without having to explicitly specify the schema name when querying objects.
+
+### Access control
+
+You can manage access control for schemas by granting or revoking privileges for specific users or roles. Here are some commonly used privileges:
+
+- `USAGE`: Allows a user/role to access objects within the schema.
+- `CREATE`: Allows a user/role to create new objects within the schema.
+- `ALTER`: Allows a user/role to modify the schema and its objects.
+
+For example, granting `USAGE` and `CREATE` permissions to a user `john` on schema `myschema`:
+
+```sql
+GRANT USAGE, CREATE ON SCHEMA myschema TO john;
+```
+
+In summary, schemas are a powerful feature in PostgreSQL that allow you to create, manage, and organize your database objects more effectively. By understanding schemas and their capabilities, you can develop better strategies for organizing your objects and controlling access in your PostgreSQL database.

src/data/roadmaps/postgresql-dba/content/102-rdbms-concepts/100-object-model/103-rows.md

@@ -1 +1,53 @@
-# Rows
+# Rows
+
+# Rows in PostgreSQL
+
+Rows, also known as "tuples" in PostgreSQL, represent individual records in a table. They are a fundamental part of the PostgreSQL object model because they store the data you will manipulate and query throughout your time as a Database Administrator. In this section, we will delve deeper into the topic of rows, and explore their properties and how they are managed within your database.
+
+## Properties of Rows
+
+A few key properties distinguish rows in PostgreSQL:
+
+1. **Order**: Although the SQL standard does not enforce a specific order for rows in a table, PostgreSQL stores tuples in a deterministic order based on their primary keys or the method of insertion.
+
+2. **Uniqueness**: The uniqueness of rows is generally enforced through either a primary key, unique constraint, or unique index, which guarantees that no two rows in a table have the same set of values for specified columns.
+
+3. **Immutability**: Rows in PostgreSQL are immutable, which means that once a row has been created, it cannot be updated. Instead, an "update" operation results in a new row being made to represent the updated state of the record, and the original row is marked for deletion.
+
+4. **Visibility**: A row in PostgreSQL can have different visibility levels depending on transactions' isolation levels or concurrent changes. This concept is important to understand for managing and maintaining transaction management and concurrency in PostgreSQL.
+
+## Managing Rows
+
+As a PostgreSQL database administrator, there are several ways to manage rows, including:
+
+- **INSERT**: The `INSERT` statement is used to add new rows to a table. You can specify the values for each column or use a subquery to source data from another table or external source:
+
+```sql
+INSERT INTO your_table (column1, column2)
+VALUES ('value1', 'value2');
+```
+
+- **UPDATE**: Updating an existing row involves creating a new row with the updated values and marking the old row for deletion. It is crucial to keep in mind that updating rows can cause bloat in the associated table and indexes, which may require periodic maintenance like vacuuming:
+
+```sql
+UPDATE your_table
+SET column1 = 'new_value1'
+WHERE column2 = 'value2';
+```
+
+- **DELETE**: To delete a row, mark it for removal by using the `DELETE` statement. Deleted rows remain in the table until the system decides it's safe to remove them or if you perform a vacuum operation:
+
+```sql
+DELETE FROM your_table
+WHERE column1 = 'value1';
+```
+
+## Performance Considerations
+
+Maintaining the proper design and indexing strategy for your tables is crucial for efficient row management in PostgreSQL. Some tips to consider include:
+
+- Favoring smaller, well-designed tables that minimize the need for updates, as updates cause table and index bloat.
+- Leveraging appropriate indexes to improve the efficiency of lookup, update, and delete operations.
+- Regularly performing maintenance tasks such as vacuuming, analyzing, and reindexing to keep performance optimal.
+
+In conclusion, understanding the properties of rows and their management is essential for any PostgreSQL DBA. By maintaining efficient tables, indexes, and row manipulation, you can achieve optimal performance and stability in your PostgreSQL-based applications.

src/data/roadmaps/postgresql-dba/content/102-rdbms-concepts/100-object-model/104-columns.md

@@ -1 +1,43 @@
-# Columns
+# Columns
+
+## Columns in PostgreSQL
+
+Columns are an essential part of the PostgreSQL object model. They represent the basic units of data storage within the database. In this section, we'll discuss the important aspects of columns in PostgreSQL, including data types, constraints, and column properties.
+
+### Data Types
+
+Every column in a PostgreSQL table has a specific data type, which dictates the kind of values that can be stored in the column. Some of the common data types in PostgreSQL include:
+
+- Numeric: `INTEGER`, `SMALLINT`, `BIGINT`, `NUMERIC`, `DECIMAL`, `REAL`, `DOUBLE PRECISION`
+- Character: `CHAR(n)`, `VARCHAR(n)`, `TEXT`
+- Binary data: `BYTEA`
+- Date and time: `DATE`, `TIME`, `TIMESTAMP`, `INTERVAL`
+- Boolean: `BOOLEAN`
+- Enumerated types: Custom user-defined types
+- Geometric and network types
+
+### Constraints
+
+Constraints are rules applied to columns that enforce specific conditions on the data. Constraints ensure data consistency and integrity within the table. These rules can be defined either during table creation or by altering an existing table. Some of the common constraints in PostgreSQL include:
+
+- `NOT NULL`: Ensures that a column cannot contain a NULL value
+- `UNIQUE`: Ensures that all values in a column are unique
+- `PRIMARY KEY`: A combination of NOT NULL and UNIQUE; uniquely identifies each row in a table
+- `FOREIGN KEY`: Ensures referential integrity between related tables
+- `CHECK`: Validates the values in a column by evaluating a Boolean expression
+
+### Column Properties
+
+In addition to data types and constraints, there are several properties and features associated with columns in PostgreSQL.
+
+- Default values: When a new row is added to the table, the column can be assigned a default value if no value is provided during the insert operation. Default values can be constant values, functions, or expressions.
+
+- Auto-incrementing columns: Often used for primary keys, the `SERIAL` and `BIGSERIAL` column types automatically generate unique, incremental integer values.
+
+- Identity columns: Introduced in PostgreSQL 10, identity columns provide an alternative to `SERIAL` for auto-incrementing primary keys. They offer more control and adhere to the SQL standard.
+
+- Computed columns: PostgreSQL supports computed columns using generated `ALWAYS AS` or `STORED` columns, allowing you to create columns with values derived from other columns in the same table.
+
+- Comments: You can add comments to columns by using the `COMMENT ON COLUMN` command.
+
+In summary, columns are an integral part of PostgreSQL tables, and understanding the different aspects of columns like data types, constraints, and properties are essential for effective database management.

src/data/roadmaps/postgresql-dba/content/102-rdbms-concepts/100-object-model/105-data-types.md

@@ -1 +1,91 @@
-# Data types
+# Data Types
+
+# Data Types in PostgreSQL
+
+As a PostgreSQL Database Administrator (DBA), it's essential to understand the various data types that can be used when designing and maintaining databases. This section provides an overview of the main data types used in PostgreSQL and some examples of how they can be utilized.
+
+## Numeric Data Types
+
+These are used for storing numeric values (integers and decimals). PostgreSQL has several types of numeric data types.
+
+### Integer Types:
+
+- `smallint`: 2-byte integer with a range of -32,768 to 32,767.
+- `integer`: 4-byte integer with a range of -2,147,483,648 to 2,147,483,647. Also known as `int`.
+- `bigint`: 8-byte integer with a range of -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807.
+
+### Decimal/Floating Point types:
+
+- `decimal`: Variable precision with optional scale, exact numeric value storage. Also known as `numeric`.
+- `real`: 4-byte floating-point number, 6 decimal digits precision. Also known as `float4`.
+- `double precision`: 8-byte floating-point number, 15 decimal digits precision. Also known as `float8`.
+
+## Character Data Types
+
+These data types are used for storing text or string values.
+
+- `character(n)`: Fixed-length character string, padded with spaces if necessary. Also known as `char(n)`.
+- `character varying(n)`: Variable-length character string with a maximum length of `n`. Also known as `varchar(n)`.
+- `text`: Variable-length character string with unlimited length.
+
+## Binary Data Types
+
+Used for storing binary data, such as images or serialized objects.
+
+- `bytea`: Variable-length binary string.
+
+## Date and Time Data Types
+
+These data types are used for storing date, time, and interval values.
+
+- `date`: Stores dates with the range from 4713 BC to 5874897 AD.
+- `time`: Stores time of day without time zone information.
+- `time with time zone`: Stores time of day including time zone information.
+- `timestamp`: Stores date and time without time zone information.
+- `timestamp with time zone`: Stores date and time including time zone information.
+- `interval`: Represents a time span. Can be used to add or subtract from `timestamp`, `time`, and `date` data types.
+
+## Enumeration Data Types
+
+Create custom data types that consist of a static, ordered set of values.
+
+- `enum`: User-defined enumeration consisting of a static, ordered set of values.
+
+## Geometric Data Types
+
+Used for storing geometric or spatial data, such as points, lines, and polygons.
+
+- `point`: Represents a two-dimensional point (x, y).
+- `line`: Represents a two-dimensional line.
+- `lseg`: Represents a two-dimensional line segment.
+- `box`: Represents a two-dimensional rectangular box.
+- `circle`: Represents a two-dimensional circle.
+- `polygon`: Represents a two-dimensional closed path with an arbitrary number of points.
+
+## Network Address Data Types
+
+Store Internet Protocol (IP) addresses and subnet masks.
+
+- `cidr`: Stands for "Classless Inter-Domain Routing." Stores network IP addresses and subnet masks.
+- `inet`: Stores IP addresses for both IPv4 and IPv6, along with an optional subnet mask.
+- `macaddr`: Stores Media Access Control (MAC) addresses for network interfaces.
+
+## Bit Strings Data Types
+
+Store fixed or variable length bit strings.
+
+- `bit(n)`: A fixed-length bit string with a length of `n` bits.
+- `bit varying(n)`: A variable-length bit string with a maximum length of `n` bits. Also known as `varbit(n)`.
+
+## UUID Data Type
+
+- `uuid`: Stores Universally Unique Identifiers (UUID) - 128-bit values.
+
+## JSON Data Types
+
+Store JSON (JavaScript Object Notation) and JSONB (Binary JSON) data types for more complex data structures.
+
+- `json`: Stores JSON data as plain text.
+- `jsonb`: Stores JSON data in a binary format.
+
+Knowing and understanding these data types allows the DBA to design efficient and accurate database schemas, select the appropriate data type for each column, and optimize performance.

src/data/roadmaps/postgresql-dba/content/102-rdbms-concepts/100-object-model/106-queries.md

@@ -1 +1,48 @@
-# Queries
+# Queries
+
+## Queries
+
+PostgreSQL, being an advanced and versatile relational database management system, offers various ways to efficiently perform queries on the data stored within its tables. In this section, we will cover some fundamental aspects, as well as best practices regarding query execution in PostgreSQL, ensuring you have a solid foundation for your PostgreSQL DBA journey.
+
+### SELECT statement
+
+The `SELECT` statement is the central part of any query in SQL. This is used to retrieve data from one or more tables, based on specified conditions. A simple `SELECT` query would look like the snippet shown below:
+
+```sql
+SELECT column1, column2, ... columnN
+FROM table_name
+WHERE conditions;
+```
+
+You can use various techniques to further improve the readability and optimization of your queries, such as joins, subqueries, aggregate functions, sorting, and limits.
+
+### Joins
+
+Joins combine data from two or more tables into a single result set. PostgreSQL supports various types of joins such as `INNER JOIN`, `LEFT JOIN`, `RIGHT JOIN`, and `FULL OUTER JOIN`. Make sure to choose the type of join that fits your use case in order to minimize performance overhead.
+
+### Subqueries
+
+Subqueries (or nested queries) are simply queries within queries. This can be useful when you need to manipulate or filter data based on the results of another query. Subqueries usually reside inside parentheses and can form part of several clauses, such as `SELECT`, `FROM`, and `WHERE`.
+
+### Aggregate Functions
+
+PostgreSQL provides several built-in aggregate functions, which can be used to calculate values like the sum, count, average, minimum, or maximum based on a set of rows. Some commonly used aggregate functions are `SUM()`, `COUNT()`, `AVG()`, `MIN()`, and `MAX()`.
+
+### Sorting
+
+To organize the output of a query, you can use the `ORDER BY` clause, which sorts the returned rows according to the specified column(s). By default, the ordering is ascending (`ASC`), but you can also choose descending order (`DESC`).
+
+### Limiting Results
+
+Sometimes, you might only need a certain number of results obtained from a query. You can use the `LIMIT` keyword, followed by the maximum number of rows you want to fetch, to achieve this. Additionally, you can use the `OFFSET` keyword to determine the starting point of the returned rows.
+
+### Query Performance
+
+Write efficient queries by considering the following best practices:
+
+- Minimize the number of columns and rows you retrieve: Only select the columns and rows you need.
+- Use indexes: Ensure that the columns you filter or join on have proper indexes.
+- Make use of materialized views: Store complex query results in a separate table in order to reduce the overall computation time.
+- Parallelize large queries: Break down large queries into smaller parts and execute them in parallel to improve query performance.
+
+By maintaining best practices while implementing queries in PostgreSQL, you can effectively manage the execution process of your PostgreSQL Databases.

src/data/roadmaps/postgresql-dba/content/102-rdbms-concepts/100-object-model/index.md

@@ -1 +1,35 @@
-# Object model
+# Object Model
+
+## Object Model in PostgreSQL
+
+In the context of the PostgreSQL DBA guide, the Object Model is an essential concept to grasp for managing and effectively utilizing the RDBMS. PostgreSQL, like other RDBMS, is built on the principles of the Object-Relational model, which basically means it has efficient mechanisms for managing and organizing database objects, such as tables, indexes, and procedures.
+
+### Key Database Objects
+
+PostgreSQL's object model includes several key database objects:
+
+1. **Schema**: A namespace that logically organizes other database objects, such as tables and views. The schema allows multiple objects to have the same name across different schemas without any conflicts.
+
+2. **Table**: It represents a collection of rows containing data with fixed columns that define the structure of the table.
+
+3. **Column**: A column is a defined set of data items of a specific type within a table.
+
+4. **Index**: Indexes are database objects that allow efficient retrieval of rows in a table by providing a specific lookup on one or more columns.
+
+5. **View**: A view is a virtual table constructed from queries of one or more existing tables.
+
+6. **Materialized View**: A Materialized View is a database object that contains the results of a query, similar to a view, but with the data cached locally for faster access.
+
+7. **Trigger**: A trigger is a procedural code that runs automatically based on certain specified events in the database. These events include any operations such as INSERT, UPDATE, DELETE, and TRUNCATE statements.
+
+8. **Stored Procedure**: A stored procedure is a user-defined function that is called by clients to execute some predefined operations.
+
+These are just a few of the most commonly used database objects in PostgreSQL. By understanding the roles and interdependencies of these objects, you can fully leverage the benefits that PostgreSQL offers as an advanced RDBMS.
+
+### Object Identification
+
+Each object in PostgreSQL can be uniquely identified by the combination of its name along with its schema and the owner credentials. PostgreSQL is case-sensitive for object names, and follows certain conventions for automatic case conversion.
+
+PostgreSQL allows you to create your own custom data types and operators, thereby extending the functionality of the built-in types and operators. This extensibility helps in catering to any specific requirements of your application or organization.
+
+In summary, the object model in PostgreSQL is an essential concept for managing RDBMS effectively. Understanding its key components and object-relational nature enables efficient organization and usage of database objects, which ultimately leads to better performance and maintainability in the long run.

src/data/roadmaps/postgresql-dba/content/102-rdbms-concepts/101-relational-model/100-domains.md

@@ -1 +1,58 @@
-# Domains
+# Domains
+
+## Domains
+
+In the relational model, a domain is a set of possible values, or a "type" that represents the characteristics of the data within columns of a table. Domains allow us to store, manipulate, and ensure the integrity of the data in a table. In PostgreSQL, a domain is a user-defined data type, which can consist of base types, composite types, and enumerated types, along with optional constraints such as NOT NULL and CHECK constraints.
+
+Here is a brief summary of the key aspects of domains in PostgreSQL:
+
+### 1. Domain creation
+
+To create a domain, you can use the `CREATE DOMAIN` command, as follows:
+
+```sql
+CREATE DOMAIN domain_name [AS] data_type
+[DEFAULT expression]
+[NOT NULL | NULL]
+[CHECK (constraint_expression)];
+```
+
+For example, to create a domain for storing email addresses, you can use the following command:
+
+```sql
+CREATE DOMAIN email_address AS varchar(255)
+NOT NULL
+CHECK (value ~* '^[A-Za-z0-9._%-]+@[A-Za-z0-9.-]+[.][A-Za-z]{2,4}$');
+```
+
+### 2. Domain usage
+
+Once you have created a domain, you can use it as a data type while defining the columns of a table. Here's an example:
+
+```sql
+CREATE TABLE users (
+  id serial PRIMARY KEY,
+  first_name varchar(25) NOT NULL,
+  last_name varchar(25) NOT NULL,
+  email email_address
+);
+```
+
+### 3. Domain modification
+
+To modify an existing domain, you can use the `ALTER DOMAIN` command. This command allows you to add or drop constraints, change the default value, and rename the domain. Here's an example:
+
+```sql
+ALTER DOMAIN email_address 
+SET DEFAULT 'example@example.com';
+```
+
+### 4. Domain deletion
+
+To delete a domain, you can use the `DROP DOMAIN` command. Be careful when doing this, as it will delete the domain even if it is still being used as a data type in a table:
+
+```sql
+DROP DOMAIN IF EXISTS email_address CASCADE;
+```
+
+By using domains, you can enforce data integrity, validation, and consistency throughout your database, while also making it easier to maintain and refactor your schema.

src/data/roadmaps/postgresql-dba/content/102-rdbms-concepts/101-relational-model/101-attributes.md

@@ -1 +1,27 @@
-# Attributes
+# Attributes
+
+## **Attributes**
+
+An attribute, in the context of a relational model, represents a characteristic or property of an entity. Entities are the individual instances or objects that exist within a given table, while the attributes help to store and describe these entities in a layered and structured manner. 
+
+For a better understanding of attributes, we can look at an example based on the table `students`:
+
+```
+students
+---------------
+student_id
+student_name
+birthdate
+email_address
+```
+
+In this example, the `student_id`, `student_name`, `birthdate`, and `email_address` are the attributes of each student entity in the `students` table. These attributes help describe the specific characteristics and properties that are associated with each student.
+
+### **Key Points about Attributes**
+
+- Attributes are also known as fields or columns in other databases.
+- Each attribute must have a data type, such as integer, character, boolean, etc.
+- Attributes can be simple (atomic) or complex, the latter meaning that they can store multiple values.
+- Each attribute have constraints, such as primary keys, unique keys, foreign keys, which can help enforce data integrity rules.
+- Attributes can have default values or be automatically generated, such as timestamps or serial numbers, in specific scenarios.
+- Attributes, in combination with entities, conform to the overall structure of the relational model, providing the blueprint for organizing, storing, and retrieving data in a PostgreSQL database.

src/data/roadmaps/postgresql-dba/content/102-rdbms-concepts/101-relational-model/102-tuples.md

@@ -1 +1,34 @@
-# Tuples
+# Tuples
+
+# Tuples in Relational Model
+
+In this section, we will take a look at another key component of the relational model - Tuples. We will discuss what tuples are, how they are related to tables, and their importance in the context of PostgreSQL database administration.
+
+## What are Tuples?
+
+In the context of relational databases, a tuple refers to a single row of data in a table. A tuple consists of a set of attribute values, where each attribute value corresponds to a specific column in the table. Essentially, a tuple represents a single instance of the entity defined by the table schema.
+
+In PostgreSQL, tuples are stored in data pages, and multiple tuples can be stored in a single data page, depending on their size and the configuration of the database.
+
+## Tuples and Tables
+
+The relationship between tuples and tables can be summarized as follows:
+
+- A table is a collection of tuples.
+- Each tuple within the table represents a unique instance of the entity being modeled by the table.
+- The columns of a table define the attributes of the entity, while the rows (tuples) represent instances of the entity.
+- The order of tuples in a table is unimportant; what matters is the set of attribute values in each tuple.
+
+## Importance of Tuples in PostgreSQL DBA
+
+As a PostgreSQL DBA, understanding the concept of tuples and their management is crucial for several reasons:
+
+1. **Data Integrity**: Tuples store the actual data for a table; hence, maintaining the integrity of tuples is essential for safeguarding the integrity of your database.
+
+2. **Query Performance:** Efficient retrieval and management of tuples directly impact the performance of your queries. By understanding how tuples are stored and retrieved, you can optimize your queries and database design for better performance.
+
+3. **Storage Management:** Tuples are stored in data pages, and understanding the storage mechanism will enable you to manage disk space usage and allocation more effectively.
+
+4. **Updates and Modifications:** As databases evolve, you'll often need to update, insert, or delete data. Understanding the implications of these actions on tuples will help you make better decisions when implementing changes to your database schema or data.
+
+In summary, tuples are a fundamental aspect of the relational model and crucial for the proper functioning of a PostgreSQL database. As a DBA, you'll need to have a thorough understanding of tuples to maintain data integrity, optimize query performance, and effectively manage storage in your PostgreSQL databases.

src/data/roadmaps/postgresql-dba/content/102-rdbms-concepts/101-relational-model/103-relations.md

@@ -1 +1,35 @@
-# Relations
+# Relations
+
+## Relations in the Relational Model
+
+In the context of a relational database, the term *relation* refers to a structured set of data. More specifically, a relation is defined as a set of tuples (rows) that share the same attributes (columns). Relations in a relational database are commonly referred to as *tables*.
+
+### Key Concepts
+
+#### 1. Attributes
+
+*Attributes* are the columns of a relation. They represent the properties or characteristics of the data being stored. For example, a table of employees might have attributes like `first_name`, `last_name`, `date_of_birth`, and `salary`.
+
+#### 2. Tuples
+
+*Tuples* are the rows of a relation. They store the actual data and represent individual entries in the table. Each tuple in a relation has the same attributes, but with different values assigned to them. This ensures that the data within the table is consistent and well-structured.
+
+#### 3. Schema
+
+The *schema* of a relation is the structure of the table, including its attributes, their data types, and any constraints being applied to them. The schema defines the blueprint for the relation, and any tuple stored in it must adhere to this structure.
+
+#### 4. Keys
+
+*Keys* are used to establish relationships between tuples within and across relations. A *primary key* is a unique identifier for a tuple within a relation, ensuring that no two tuples have the same primary key value. A *foreign key* refers to a primary key from another relation, creating a relationship between tuples across different relations.
+
+### Benefits of Relations
+
+1. **Data Consistency**: By enforcing a consistent structure for tuples and attributes, the relational model ensures that data is stored in a consistent and uniform manner.
+
+2. **Data Integrity**: Relations provide support for primary and foreign keys, which ensure data integrity by preventing duplicate records and maintaining relationships between records in different tables.
+
+3. **Flexibility**: The relational model allows complex queries and operations to be performed on relations, making it easier to extract and manipulate data as needed.
+
+4. **Scalability**: Relations can easily be scaled to accommodate additional tuples or attributes, making it easy to modify or expand the database as necessary.
+
+In summary, *relations* are the foundation of the relational database model, providing a well-structured and organized way to store and manipulate data. By understanding the key concepts of relations, attributes, tuples, schema, and keys, a PostgreSQL DBA can effectively design and maintain efficient and consistent databases.

src/data/roadmaps/postgresql-dba/content/102-rdbms-concepts/101-relational-model/104-constraints.md

@@ -1 +1,107 @@
-# Constraints
+# Constraints
+
+# Constraints in PostgreSQL
+
+Constraints are an integral part of the relational model in PostgreSQL. They are used to define rules and relationships between columns within a table, ensuring data integrity and consistency. Constraints allow you to enforce specific conditions on columns or tables and control the kind of data that can be stored within them. In this section, we will explore various types of constraints and their usage in PostgreSQL.
+
+## Types of Constraints
+
+There are several types of constraints available in PostgreSQL:
+
+1. `NOT NULL`: It ensures that a column cannot have a NULL value.
+2. `UNIQUE`: It ensures that all values in a column are unique. No two rows can contain the same value in a unique column.
+3. `PRIMARY KEY`: It is a special type of UNIQUE constraint that uniquely identifies each row in a table. A primary key column cannot contain NULL values.
+4. `FOREIGN KEY`: It establishes a relationship between columns in different tables, ensuring that the data in one table corresponds to the data in another table.
+5. `CHECK`: It verifies that the data entered into a column satisfies a specific condition.
+
+## Defining Constraints
+
+Constraints can be defined at the column level or table level. You can define them when creating a table or add them later using the `ALTER TABLE` statement. Let's take a look at some examples:
+
+### NOT NULL
+
+To define a NOT NULL constraint when creating a table:
+
+```sql
+CREATE TABLE customers (
+  id SERIAL PRIMARY KEY,
+  name VARCHAR(100) NOT NULL,
+  email VARCHAR(255) NOT NULL
+);
+```
+
+### UNIQUE
+
+To define a UNIQUE constraint when creating a table:
+
+```sql
+CREATE TABLE users (
+  id SERIAL PRIMARY KEY,
+  username VARCHAR(50) NOT NULL UNIQUE,
+  email VARCHAR(255) NOT NULL UNIQUE
+);
+```
+
+### PRIMARY KEY
+
+To define a PRIMARY KEY constraint when creating a table:
+
+```sql
+CREATE TABLE products (
+  id SERIAL PRIMARY KEY,
+  name VARCHAR(100) NOT NULL,
+  price NUMERIC NOT NULL
+);
+```
+
+### FOREIGN KEY
+
+To define a FOREIGN KEY constraint when creating a table:
+
+```sql
+CREATE TABLE orders (
+  id SERIAL PRIMARY KEY,
+  customer_id INTEGER REFERENCES customers(id),
+  product_id INTEGER REFERENCES products(id),
+  quantity INTEGER NOT NULL
+);
+```
+
+### CHECK
+
+To define a CHECK constraint when creating a table:
+
+```sql
+CREATE TABLE orders (
+  id SERIAL PRIMARY KEY,
+  customer_id INTEGER REFERENCES customers(id),
+  product_id INTEGER REFERENCES products(id),
+  quantity INTEGER CHECK(quantity > 0)
+);
+```
+
+## Managing Constraints
+
+You can modify, disable or drop constraints using various `ALTER TABLE` statements. Some examples are:
+
+- Adding a UNIQUE constraint to an existing table:
+
+  ```sql
+  ALTER TABLE users ADD CONSTRAINT unique_email UNIQUE(email);
+  ```
+
+- Dropping a CHECK constraint:
+
+  ```sql
+  ALTER TABLE orders DROP CONSTRAINT check_quantity;
+  ```
+
+- Disabling a FOREIGN KEY constraint:
+
+  ```sql
+  ALTER TABLE orders ALTER CONSTRAINT fk_customer_id DEFERRABLE;
+  ```
+
+## Conclusion
+
+Constraints play a crucial role in maintaining data integrity and consistency within a PostgreSQL database. By understanding and utilizing various types of constraints, you can ensure that your database maintains a high level of quality and reliability.

src/data/roadmaps/postgresql-dba/content/102-rdbms-concepts/101-relational-model/105-null.md

@@ -1 +1,50 @@
-# Null
+# NULL
+
+### Null Values in PostgreSQL
+
+In the relational model, `null` is a special marker that signifies the absence of a value for a specific attribute. In other words, it represents the "unknown" or "undefined" state of a particular column in a relational database. This chapter will discuss the key aspects and implications of using null values in PostgreSQL.
+
+#### Why Null is important?
+
+Often, in real-world databases, there might be situations where we do not have all the necessary information to complete a record. For instance, when a new customer registers for an online shopping platform, they might provide their name and email, but leave the optional phone number field blank. In such cases, PostgreSQL uses null to store such empty fields.
+
+#### Handling Null in PostgreSQL
+
+It is important to understand how to work with null values in PostgreSQL since they have their own unique set of rules, especially when it comes to querying data. Here are some important points to consider while dealing with null values:
+
+1. *Comparison Operators*: Comparing null values can be tricky. Regular comparison operators, such as '=' or '<>', will return null when used with a null value. To specifically check for null, use the `IS NULL` or `IS NOT NULL` condition.
+
+   ```sql
+   SELECT * FROM customers WHERE phone_number IS NULL;
+   ```
+
+2. *Aggregate Functions*: Most aggregate functions like `COUNT()`, `AVG()`, `SUM()` etc., ignore null values when applied to a set of records.
+
+   ```sql
+   SELECT AVG(salary) FROM employees WHERE department = 'HR';
+   ```
+   This query will return the average salary of non-null records in the HR department.
+
+3. *Null in Joins*: When using joins, records with null values in the join column will be ignored, unless you are using an outer join.
+
+4. *Inserting Null values*: To insert a null value for a column while adding a new record to the table, use the `DEFAULT` keyword or simply leave the field value empty.
+
+   ```sql
+   INSERT INTO customers (name, email, phone_number) VALUES ('John Doe', 'john@example.com', DEFAULT);
+   ```
+
+5. *Updating records with Null*: You can set a column value to null using an UPDATE query.
+
+   ```sql
+   UPDATE customers SET phone_number = NULL WHERE email = 'john@example.com';
+   ```
+
+6. *Coalesce function*: To handle null values and provide a default value in case of null, you can use the `COALESCE()` function. It accepts a list of arguments and returns the first non-null value.
+
+   ```sql
+   SELECT COALESCE(phone_number, 'N/A') as phone_number FROM customers;
+   ```
+
+#### Conclusion
+
+Understanding the concept of null values in PostgreSQL is essential as a DBA because they are commonly encountered while working with real-world data. Handling nulls correctly ensures accurate query results and maintains data integrity within the database. With this foundational knowledge on nulls, you now have a better grasp on its implications and can handle them more effectively in PostgreSQL.

src/data/roadmaps/postgresql-dba/content/102-rdbms-concepts/101-relational-model/index.md

@@ -1 +1,36 @@
-# Relational model
+# Relational Model
+
+## Relational Model
+
+The Relational Model is the foundation of relational database systems, which are widely used for managing structured data. This model simplifies the organization and management of data by representing it as tables (or relations) with rows and columns. Each column of a table represents a specific attribute (or field) of the data, while each row represents a single record (or tuple) of that data. The model was proposed by Dr. E.F. Codd in 1970, and ever since, it has played a pivotal role in the development of modern database management systems, such as PostgreSQL.
+
+### Key Concepts
+
+- **Relation**: A relation, in the context of the relational model, is a table that holds data. It consists of rows (tuples) and columns (attributes).
+
+- **Attribute**: An attribute represents a specific property or characteristic of the data. For example, in a table containing information about employees, attributes could be 'name', 'age', 'job_title', and 'salary'.
+
+- **Tuple**: A tuple is a single record or instance of data within a relation. It is composed of a set of attribute values.
+
+- **Schema**: The schema is the structure or blueprint of a relation, which describes the names and data types of its attributes.
+
+- **Key**: A key uniquely identifies a tuple within a relation. Primary keys are the main means of identifying records, while foreign keys establish relationships between tables.
+
+- **Normalization**: Normalization is the process of organizing data in a database so as to minimize redundancy and improve data integrity. It involves decomposing larger tables into smaller, more manageable ones and defining relationships between them.
+
+### Advantages
+The relational model provides several advantages for data management, including:
+
+1. **Data Independence**: The relational model allows for data independence, which means that applications or users can interact with data without needing to know the specific storage and retrieval methods.
+
+2. **Integrity Constraints**: The relational model supports the enforcement of integrity constraints, ensuring that the data remains consistent and accurate over time.
+
+3. **Data Manipulation**: The Structured Query Language (SQL) is closely linked to the relational model, providing a powerful and standardized means of retrieving, inserting, updating, and deleting data.
+
+4. **Flexibility**: The relational model is adaptable to various applications and industries, making it a popular choice for managing data in diverse environments.
+
+5. **Easier Data Modeling**: The use of tables for organizing data makes it easy to understand the structure, relationships, and dependencies within the database.
+
+6. **Scalability**: The relational model is well-suited for both small-scale and large-scale databases, providing the flexibility to accommodate changing data storage needs.
+
+In conclusion, the relational model has been, and continues to be, a popular choice for organizing and managing structured data in database management systems, such as PostgreSQL. With its foundation in tables, attributes, and keys, the relational model provides a powerful, flexible, and scalable means of handling data across a wide range of applications and industries.

src/data/roadmaps/postgresql-dba/content/102-rdbms-concepts/102-high-level-database-concepts/100-acid.md

@@ -1 +1,50 @@
-# Acid
+# ACID
+
+## ACID Properties
+
+ACID stands for Atomicity, Consistency, Isolation, and Durability. These are the fundamental principles that help ensure the reliability of any database management system (DBMS), including PostgreSQL. A DBMS that adheres to ACID properties maintains correct and consistent data throughout its various transactions. Let's briefly discuss each principle.
+
+### Atomicity
+
+Atomicity refers to the all-or-nothing principle in which a transaction either completes in its entirety or fails without making any changes. This means that if any part of the transaction fails, the entire transaction is rolled back to its initial state, ensuring that no partial or intermediate changes are written to the database.
+
+Example:
+```sql
+BEGIN;
+INSERT INTO employees (name, salary) VALUES ('John Doe', 50000);
+UPDATE employees SET salary = salary + 1000 WHERE name = 'Jane Smith';
+INSERT INTO employees (name, salary) VALUES ('Mark Johnson', 60000);
+-- If any of these queries fail, the entire transaction is rolled back.
+COMMIT;
+```
+
+### Consistency
+
+Consistency ensures that the database remains in a consistent state before and after every transaction. This means that a transaction can only bring a DB from one consistent state to another consistent state. Constraints, cascading actions, and triggers help enforce consistency.
+
+Example:
+```sql
+ALTER TABLE employees ADD CONSTRAINT salary_check CHECK (salary > 0);
+```
+
+### Isolation
+
+Isolation involves ensuring that concurrent transactions do not interfere with one another. When multiple transactions run simultaneously, the system should behave as if the transactions were executed serially, one after another. Isolation also helps prevent scenarios like dirty reads, non-repeatable reads, and phantom reads.
+
+In PostgreSQL, you can enforce different isolation levels using the following syntax:
+
+```sql
+SET TRANSACTION ISOLATION LEVEL { SERIALIZABLE | REPEATABLE READ | READ COMMITTED | READ UNCOMMITTED };
+```
+
+### Durability
+
+Durability guarantees that once a transaction has been committed, the changes made by that transaction become permanent. This means that even in the event of system crashes or power failures, the data must be recoverable and persistent. PostgreSQL uses write-ahead logging (WAL) to ensure data durability.
+
+Example of using WAL to achieve durability:
+```sql
+-- This command sets the minimum level of the write-ahead log (WAL) to make sure that changes are written to disk.
+ALTER SYSTEM SET wal_level = 'replica';
+```
+
+In conclusion, ACID properties help in maintaining the reliability, accuracy, and consistency of a database system like PostgreSQL. By understanding and applying these principles, you as a PostgreSQL DBA can effectively manage your database and ensure smooth operation.

src/data/roadmaps/postgresql-dba/content/102-rdbms-concepts/102-high-level-database-concepts/101-mvcc.md

@@ -1 +1,33 @@
-# Mvcc
+# MVCC
+
+## Multi-Version Concurrency Control (MVCC)
+
+One of the most important concepts in PostgreSQL for maintaining data consistency and handling simultaneous transactions is **Multi-Version Concurrency Control (MVCC)**.
+
+### What is MVCC?
+
+MVCC is a technique used by PostgreSQL to allow concurrent access to the database by multiple users without conflicts. It does this by creating a separate snapshot of the database for each transaction. Instead of locking the data when a row is being read or modified, PostgreSQL uses these snapshots to present users with a consistent view of the data. This way, they can work concurrently without data inconsistencies or delays due to locks.
+
+### How does MVCC work?
+
+Here's an overview of how MVCC works in PostgreSQL:
+
+1. **Transactions and Snapshots:** When a transaction starts, PostgreSQL creates a snapshot of the database at that point in time. Any changes made within the transaction are not visible to other transactions until it's committed.
+
+2. **Row Versioning:** Whenever a row is modified, PostgreSQL creates a new row version with the changes rather than updating the existing row. Each row version has a unique system-generated transaction ID.
+
+3. **Visibility Rules:** When a transaction reads a row, PostgreSQL checks the transaction ID and the row version to determine if the row is visible to the transaction. This ensures that each transaction sees a consistent view of the data according to its snapshot.
+
+4. **Vacuuming:** Since multiple row versions are created due to MVCC, PostgreSQL needs to periodically clean up these old and unused row versions. This process is known as 'vacuuming'. The `VACUUM` command reclaims storage space, optimizes the performance of the database, and removes dead row versions.
+
+### Benefits of MVCC
+
+- **Concurrency:** MVCC allows multiple transactions to run concurrently without causing data inconsistency or delays due to locking.
+
+- **Isolation:** Each transaction works on a consistent snapshot of the database, ensuring proper isolation between transactions.
+
+- **Consistency:** MVCC ensures that only the committed changes are visible to other transactions, providing a consistent view of the data.
+
+- **Reduced Lock Contention:** By avoiding locks for read and write operations, MVCC minimizes lock contention and improves the overall performance of the database.
+
+In summary, MVCC provides a way for PostgreSQL to handle concurrent transactions efficiently while maintaining data consistency, avoiding contention, and ensuring reliable performance. As a PostgreSQL DBA, understanding the concept of MVCC will help you in managing and optimizing your databases effectively.

src/data/roadmaps/postgresql-dba/content/102-rdbms-concepts/102-high-level-database-concepts/102-transactions.md

@@ -1 +1,45 @@
-# Transactions
+# Transactions
+
+## Transactions
+
+A *transaction* is a single sequence of one or more SQL operations (queries, updates, or other data manipulations) that are executed as a single unit of work. They allow databases to remain in a consistent and predictable state even when multiple users are modifying the data concurrently.
+
+In PostgreSQL, a transaction can be defined using the `BEGIN`, `COMMIT`, and `ROLLBACK` SQL statements. It's essential to understand the main concepts within transactions, such as the ACID properties, isolation levels, and concurrency issues. 
+
+### ACID Properties
+
+Transactions provide ACID properties, which are essential for maintaining data consistency and integrity:
+
+1. **Atomicity**: A transaction is either fully completed or not executed at all. If any operation within the transaction fails, the entire transaction is aborted and rolled back.
+
+2. **Consistency**: The database remains in a consistent state before and after each transaction. All constraints, rules, and triggers must be satisfied in every transaction's final state.
+
+3. **Isolation**: Each transaction occurs independently and does not affect other ongoing transactions. The state of the database during one transaction should not be visible to other concurrent transactions.
+
+4. **Durability**: Once a transaction is committed, the changes to the data are permanent, even in the case of system failure.
+
+### Isolation Levels
+
+PostgreSQL offers different transaction isolation levels, which define the visibility of changes made by other concurrent transactions:
+
+1. **Read Uncommitted**: The lowest level of isolation, allowing a transaction to see uncommitted changes made by other transactions. This level is not supported in PostgreSQL.
+
+2. **Read Committed**: A transaction can only see changes committed before it started or those committed during its execution. This is the default isolation level in PostgreSQL.
+
+3. **Repeatable Read**: A transaction sees a consistent snapshot of the database at the time the transaction begins, providing a higher level of isolation than Read Committed. 
+
+4. **Serializable**: The highest level of isolation, ensuring that transactions will behave as if they were executed sequentially.
+
+You can set the isolation level for a specific transaction using the `SET TRANSACTION` command, followed by the `ISOLATION LEVEL` keyword and the desired level.
+
+### Concurrency Issues
+
+When running transactions concurrently, some issues may arise that can affect data consistency and integrity, such as:
+
+- **Dirty Read**: A transaction reads data written by an uncommitted transaction.
+- **Non-repeatable Read**: A transaction reads the same data more than once, but the data is changed by another transaction during that time.
+- **Phantom Read**: A transaction reads a set of data that meets specific criteria, but another concurrent transaction adds or removes rows that meet the criteria.
+
+To prevent these issues, PostgreSQL uses a multi-version concurrency control (MVCC) model, ensuring that each transaction sees a consistent snapshot of the data and allowing high concurrency levels without the need for locks.
+
+By understanding transactions and their essential concepts, you can effectively manage data changes, ensuring data consistency and integrity in your PostgreSQL databases.

src/data/roadmaps/postgresql-dba/content/102-rdbms-concepts/102-high-level-database-concepts/103-write-ahead-log.md

@@ -1 +1,33 @@
-# Write ahead log
+# Write-ahead Log
+
+## Write Ahead Log (WAL)
+
+A fundamental concept in database management, especially for disaster recovery and crash recovery, is the Write Ahead Log (WAL). It is a technique used by PostgreSQL to ensure that data modifications are written to a log file *before* they are written to the main database.
+
+### Purpose of WAL
+
+The main purpose of the WAL is to enable:
+
+1. __Durability__: Ensuring that once a transaction has been committed, all changes made by the transaction are permanently stored in the database, even in case of a crash.
+2. __Crash Recovery__: WAL helps the database recover to a consistent state after an unexpected system shutdown or crash.
+
+### How WAL Works
+
+PostgreSQL follows a simple yet effective strategy called "Write-Ahead Logging" for maintaining the WAL:
+
+1. Every time a transaction makes changes to the database (e.g., insert, delete, or update records), the database records the changes (also known as "diffs") in the WAL before applying it to the main database.
+2. Only after writing the WAL records, the actual data is written and updated in the main database.
+3. The changes are confirmed, and the transaction is marked as committed.
+4. Periodically, the WAL records are "flushed" (i.e., written permanently) to the main database, in a process called "checkpoint".
+
+### Checkpoints
+
+A checkpoint is an operation in which PostgreSQL writes all the data changes made by completed transactions to the main data files. PostgreSQL performs checkpoints to minimize data loss and reduce recovery time in case of a crash. The configuration parameters `checkpoint_timeout` and `max_wal_size` define the frequency and the maximum amount of WAL data between two checkpoints.
+
+### WAL Archiving
+
+PostgreSQL provides a feature called "WAL Archiving" that allows you to archive completed WAL files for long-term storage. Archiving WAL files is useful for taking base backups and providing a continuous backup solution to recover to a specific point in time. To enable WAL archiving, you need to set the `archive_mode` configuration parameter to 'on' and define the `archive_command` to specify how the WAL files should be archived.
+
+### Conclusion
+
+Write Ahead Log (WAL) is an integral part of the PostgreSQL database system, ensuring the durability of transactional data and enabling crash recovery. Understanding WAL's working process can help you manage, optimize, and troubleshoot your PostgreSQL database effectively.

src/data/roadmaps/postgresql-dba/content/102-rdbms-concepts/102-high-level-database-concepts/104-query-processing.md

@@ -1 +1,33 @@
-# Query processing
+# Query Processing
+
+## Query Processing
+
+Query processing is an essential aspect of PostgreSQL database management, as it directly impacts database performance and efficiency. This section provides an overview of query processing in PostgreSQL, covering its key components and stages.
+
+### Overview
+
+In PostgreSQL, query processing refers to the various steps and procedures involved in transforming a high-level query language (such as SQL) into a format understood by the underlying database system. Effective query processing ensures the prompt and accurate retrieval of data, as well as the efficient execution of database operations.
+
+### Stages of Query Processing
+
+PostgreSQL's query processing typically consists of three main stages:
+
+1. **Parsing**: During this stage, the PostgreSQL parser decomposes the high-level SQL query into a parse tree. This involves checking for syntax errors and validating the query structure.
+
+2. **Optimization**: The query optimizer then analyzes the parse tree and determines the most efficient way to execute the query. This can involve multiple techniques, such as reorganizing the query, selecting the appropriate access methods, and estimating the cost of different execution plans. The primary goal of optimization is to minimize the execution time and resource usage while maintaining accurate results.
+
+3. **Execution**: After optimization, the actual execution of the query takes place. PostgreSQL carries out the steps outlined in the optimized plan, accessing the relevant database objects, processing the data, and returning the results to the user or application.
+
+### Key Components
+
+PostgreSQL's query processing is influenced by several critical components:
+
+- **Parser**: The parser is responsible for breaking down the query into a structured format, which is essential for subsequent processing. It verifies the syntax and structure of the given SQL statement.
+
+- **Optimizer**: This component is responsible for determining the optimal execution plan for the query. It evaluates potential plans and selects the one with the lowest estimated cost in terms of processing time, memory usage, and I/O overhead.
+
+- **Executor**: The executor carries out the specific operations and data retrieval tasks outlined in the optimization plan. It is responsible for accessing the necessary data, performing joins, filtering results, and producing the final data set.
+
+- **Statistics Collector**: PostgreSQL's statistics collector gathers information about the database objects and their usage patterns. This data is crucial for the optimizer, as it helps determine the most efficient access paths and estimate the cost of different plans.
+
+By understanding query processing and its various components, a PostgreSQL DBA can better maintain and optimize the database's performance. This knowledge is essential for ensuring smooth operation and achieving the best possible results for each query.

src/data/roadmaps/postgresql-dba/content/102-rdbms-concepts/102-high-level-database-concepts/index.md

@@ -1 +1,87 @@
-# High level database concepts
+# High Level Database Concepts
+
+# High-Level Database Concepts
+
+In this section, we will discuss key high-level concepts that are crucial for understanding and effectively managing PostgreSQL databases. Let's dive in!
+
+## Relational Database Management System (RDBMS)
+
+A Relational Database Management System (RDBMS) is a software system that allows you to create, update, and manage a relational database. Some popular RDBMSs include PostgreSQL, MySQL, Oracle, and SQL Server. In an RDBMS, data is organized in tables - consisting of rows and columns - and these tables are related to one another through keys.
+
+### Tables
+
+A table is a collection of related data, organized in *rows* and *columns*. Columns represent attributes or properties of the data, whereas rows represent individual records or instances of data.
+
+For example, consider a table representing `employees`. Each row would represent a single employee, and columns describe employee attributes such as `employee_id`, `first_name`, `last_name`, etc.
+
+### Columns
+
+Columns are the attributes or properties that describe data within a table. They are also called fields, and each column has a specific name and data type.
+
+For example, in the `employees` table, we might have columns for employee details:
+
+- `employee_id`: Integer, uniquely identifies an employee.
+- `first_name`: String, represents the employee's first name.
+- `last_name`: String, represents the employee's last name.
+- `dob`: Date, represents the employee's date of birth.
+
+### Rows
+
+Rows, also known as records, represent individual instances or entries in a table. They contain values for each of the columns in the table.
+
+Continuing the `employees` table example, a row might contain the following data:
+
+- `employee_id`: 1
+- `first_name`: "John"
+- `last_name`: "Doe"
+- `dob`: "1990-01-01"
+
+### Keys
+
+Keys are used to establish relationships between tables and enforce constraints, such as ensuring uniqueness or referential integrity.
+
+- **Primary Key**: A primary key uniquely identifies each record in a table. A table can only have one primary key, and its values must be unique and non-null.
+- **Foreign Key**: A foreign key refers to a primary key from another table, helping to establish relationships between tables and ensure referential integrity.
+
+## SQL (Structured Query Language)
+
+SQL is the standard language used to interact with RDBMSs such as PostgreSQL. SQL allows you to perform a wide range of tasks including data definition, manipulation, control, and querying.
+
+### Data Definition Language (DDL)
+
+DDL includes statements for defining and altering the structure of database objects, such as tables, indexes, and views.
+
+Examples of DDL statements include:
+
+- `CREATE TABLE`: defines a new table in the database.
+- `ALTER TABLE`: modifies an existing table.
+- `DROP TABLE`: removes a table from the database.
+
+### Data Manipulation Language (DML)
+
+DML includes statements for managing the data stored within tables, such as inserting, updating, or deleting records.
+
+Examples of DML statements include:
+
+- `INSERT`: adds a new record to a table.
+- `UPDATE`: modifies an existing record in a table.
+- `DELETE`: removes a record from a table.
+
+### Data Query Language (DQL)
+
+DQL includes statements for obtaining information from the database, such as retrieving data or generating reports.
+
+Examples of DQL statements include:
+
+- `SELECT`: retrieves data from one or more tables or other database objects.
+
+### Data Control Language (DCL)
+
+DCL includes statements for managing user permissions and access control within the database.
+
+Examples of DCL statements include:
+
+- `GRANT`: gives a user specific privileges on a database object.
+- `REVOKE`: removes privileges on a database object from a user.
+
+In summary, understanding high-level database concepts such as tables, keys, and SQL is critical for effectively managing PostgreSQL databases. By gaining proficiency in these topics, you can more easily navigate and work with your database structures and data.

src/data/roadmaps/postgresql-dba/content/102-rdbms-concepts/index.md

@@ -1 +1,48 @@
-# Rdbms concepts
+# Basic RDBMS Concepts
+
+# RDBMS Concepts
+
+As a PostgreSQL Database Administrator (DBA), it is crucial to understand the basic concepts of a Relational Database Management System (RDBMS). As PostgreSQL is an RDBMS, having a clear understanding of these concepts will increase your proficiency in managing and optimizing your database system. In this section, we will cover some key RDBMS concepts.
+
+## 1. Introduction to RDBMS
+
+A **Relational Database Management System (RDBMS)** is a type of database management system which stores data in tables, structured based on relationships among the data points, thus making it easier to manage, retrieve, and modify. The primary benefit of using an RDBMS is that it maintains data integrity, minimizes data redundancy, and provides a flexible data management approach.
+
+## 2. Tables
+
+**Tables** form the building blocks of an RDBMS, and they store data in rows and columns. Each table has a unique name and consists of elements called _attributes_ (columns) and _tuples_ (rows).
+
+- Rows: Represent a single data entry in the table.
+- Columns: Define the structure of the table, specifying the type of data to be stored in each column.
+
+## 3. Keys
+
+A **key** in an RDBMS is an attribute (or a set of attributes) that uniquely identifies a row in a table. There are different types of keys:
+
+- Primary Key: A unique identifier for a row in the table.
+- Foreign Key: A set of columns referencing the primary key of another table, used to maintain relationships across tables.
+- Candidate Key: A unique attribute (or set of attributes) that can be chosen as the primary key.
+- Composite Key: A key made up of a set of attributes used to identify unique rows in the table.
+
+## 4. Relationships
+
+One of the main features of an RDBMS is the ability to represent relationships among tables. The most common types of relationships are:
+
+- One-to-One: A single row in table A is related to a single row in table B.
+- One-to-Many: A single row in table A is related to multiple rows in table B.
+- Many-to-Many: Multiple rows in table A are related to multiple rows in table B.
+
+## 5. Schema
+
+A **schema** in an RDBMS is a logical container for database objects (tables, views, functions, indexes, etc.). Schemas help to organize and manage the database structure by grouping related objects.
+
+## 6. ACID Properties
+
+RDBMS follows the ACID properties to ensure data consistency and reliable transactions:
+
+- Atomicity: A transaction is either completed entirely or not executed at all.
+- Consistency: A transaction cannot violate the database's integrity constraints.
+- Isolation: Each transaction is isolated from others, and its effect is not visible until it is completed.
+- Durability: Once a transaction is committed, its effect is permanently saved in the database.
+
+By understanding these fundamental RDBMS concepts, you will be better equipped to manage and optimize a PostgreSQL database. As a PostgreSQL DBA, knowledge of these concepts is essential for designing and maintaining a robust and efficient system.

src/data/roadmaps/postgresql-dba/content/103-installation-and-setup/100-package-managers.md

@@ -1 +1,49 @@
-# Package managers
+# Package Managers
+
+## Package Managers
+
+Package managers are essential tools in the software world that simplify the process of installing, upgrading, configuring, and removing software packages in a consistent manner. In the context of our PostgreSQL DBA guide, specifically in the "installation and setup" topic, package managers can be used to quickly and easily install and manage PostgreSQL on different operating systems.
+
+There are various package managers available depending on the type of operating system you are using. Here, we provide an overview of some widely used package managers and their corresponding operating systems:
+
+### APT (Advanced Package Tool) - Debian-based systems
+
+APT is the default package manager for Debian-based systems like Ubuntu, Debian, and Linux Mint. It provides a simple way to install, remove, and upgrade software packages using commands like `apt-get` and `apt-cache`.
+
+Example command to install PostgreSQL on an APT-based system:
+
+```
+sudo apt-get install postgresql
+```
+
+### YUM (Yellowdog Updater Modified) - Red Hat-based systems
+
+YUM is the default package manager for Red Hat-based systems like Fedora, CentOS, and RHEL (Red Hat Enterprise Linux). Yum is built on top of RPM (Red Hat Package Manager), and provides advanced functionalities for managing package dependencies, repositories, and updates.
+
+Example command to install PostgreSQL on a YUM-based system:
+
+```
+sudo yum install postgresql-server
+```
+
+### DNF (Dandified YUM) - Modern Red Hat-based systems
+
+DNF is the next-generation package manager for Fedora and other modern Red Hat-based systems that have replaced Yum. DNF aims to improve performance, simplify the codebase, and provide better package management features.
+
+Example command to install PostgreSQL on a DNF-based system:
+
+```
+sudo dnf install postgresql-server
+```
+
+### Homebrew - macOS
+
+Homebrew is not a default package manager for macOS, but is widely used as an alternative to easily install and manage software packages on macOS. Homebrew has a wide range of packages available, including PostgreSQL.
+
+Example command to install PostgreSQL using Homebrew:
+
+```
+brew install postgresql
+```
+
+As you continue with the PostgreSQL DBA guide, remember to choose the appropriate package manager for your operating system to ensure a smooth installation and setup experience. If you are unsure about any steps or commands, consult the official documentation specific to your package manager for help.

src/data/roadmaps/postgresql-dba/content/103-installation-and-setup/101-using-docker.md

@@ -1 +1,52 @@
-# Using docker
+# Using Docker
+
+## Using Docker for PostgreSQL DBA
+
+Docker is an open-source platform that simplifies the process of creating, deploying, and running applications in isolated containers. It is particularly helpful for managing PostgreSQL databases, as it eliminates the need for complicated setup and configuration processes.
+
+### Advantages of Using Docker
+
+1. **Simplified Setup and Installation**: Quickly deploy and manage PostgreSQL instances within seconds, eliminating the need for an extensive setup process.
+2. **Isolation**: Each container runs independently, ensuring that any changes or issues in one container do not impact others.
+3. **Portability**: Ensure your PostgreSQL instances can easily be run on various platforms and environments, thanks to Docker's containerization.
+
+### Getting Started with Docker
+
+1. **Install Docker**: To get started with Docker, you'll need to have it installed on your machine. Visit the [official Docker website](https://www.docker.com/products/docker-desktop) to download and install Docker Desktop for your operating system.
+
+2. **Pull PostgreSQL Image**: With Docker installed, you can now pull the PostgreSQL image from Docker Hub. Open your terminal or command prompt and run the following command:
+
+```bash
+docker pull postgres
+```
+
+This command will download the latest official PostgreSQL image.
+
+3. **Start the PostgreSQL Container**: To run the PostgreSQL instance, use the following command:
+
+```bash
+docker run --name my-postgres -e POSTGRES_PASSWORD=mysecretpassword -p 5432:5432 -d postgres
+```
+
+Make sure to replace 'mysecretpassword' with your desired password. This command will create and start a new PostgreSQL container named 'my-postgres', with the specified password.
+
+4. **Connect to the PostgreSQL Instance**: Once the container is running, you can connect to the PostgreSQL instance using a tool like `psql` or an application that supports PostgreSQL connections (such as [pgAdmin](https://www.pgadmin.org/)).
+
+For example, to connect using `psql`, run the following command:
+
+```bash
+psql -h localhost -U postgres -W
+```
+
+When prompted, enter the password you set earlier ('mysecretpassword'), and you should now be connected to your PostgreSQL instance.
+
+5. **Useful Docker Commands**:
+
+- List running containers: `docker ps`
+- Stop a container: `docker stop <container_name>`
+- Start a container: `docker start <container_name>`
+- Remove a container: `docker rm <container_name>`
+- List all available images: `docker images`
+- Remove an image: `docker rmi <image_name>`
+
+With Docker, managing your PostgreSQL instances is quick and easy. Simply follow the steps and commands provided in this guide to install, set up, and connect to your PostgreSQL instances using Docker.

src/data/roadmaps/postgresql-dba/content/103-installation-and-setup/102-connect-using-psql.md

@@ -1 +1,53 @@
-# Connect using psql
+# Connect using `psql`
+
+## Connect using psql
+
+`psql` is a command-line utility that comes with PostgreSQL to easily interact with the database server. It is a powerful tool that provides a feature-rich querying interface for executing SQL commands, managing databases, users, and more. In this section, we will discuss how to connect to a PostgreSQL database using `psql`.
+
+### Prerequisites
+
+Before you can use `psql` to connect to a PostgreSQL server, make sure you have the following:
+
+- PostgreSQL server is up and running.
+- Required access to connect with the target database (username, password, and database name).
+
+### Connecting to a Database
+
+To connect to a PostgreSQL database using `psql`, open up a terminal on the machine where you have PostgreSQL installed and follow the steps below.
+
+1. **Use the following command format to connect to a database:**
+
+   ```bash
+   psql -h <hostname> -p <port> -U <username> -d <database_name>
+   ```
+
+   Replace the following placeholders in the command above:
+   - `<hostname>`: The address of the machine where the PostgreSQL server is running on (localhost, if on the same machine as psql).
+   - `<port>`: The port number on which the PostgreSQL server is listening (default is 5432).
+   - `<username>`: The PostgreSQL user you want to connect as.
+   - `<database_name>`: The name of the database you want to connect to.
+
+   For example, if you want to connect to a database named `mydb` on a localhost as a user named `postgre`, the command would look like:
+
+   ```bash
+   psql -h localhost -p 5432 -U postgre -d mydb
+   ```
+
+2. **Enter your password:** After running the command, you will be prompted to enter the password for the specified user. Enter the password and press `Enter`.
+
+3. **Connected to the Database:** If the connection is successful, you will see the `psql` prompt that looks like below, and you can start executing SQL commands:
+
+   ```
+   postgre=>
+   ```
+
+### Basic psql Commands
+
+Here are some basic `psql` commands to get you started:
+
+- `\l`: List all databases.
+- `\dt`: List all tables in the currently connected database.
+- `\c <database_name>`: Connect to another database.
+- `\q`: Quit the psql program.
+
+Now you should be able to connect to a PostgreSQL database using `psql`. Happy querying!

src/data/roadmaps/postgresql-dba/content/103-installation-and-setup/103-deployment-in-cloud.md

@@ -1 +1,47 @@
-# Deployment in cloud
+# Deployment in Cloud
+
+# Deployment of PostgreSQL DBA in the Cloud
+
+In this section, we will discuss how to deploy PostgreSQL in various cloud service environments. Cloud computing has become increasingly popular for hosting applications and databases. Cloud-based deployment of PostgreSQL can provide better scalability, high availability, and ease of management.
+
+## Advantages of Cloud Deployment
+
+There are several advantages to deploying PostgreSQL in the cloud:
+
+1. **Scalability**: Cloud services enable you to scale up or down your PostgreSQL deployment based on demand. You can easily add additional resources or storage capacity to accommodate growth in your database.
+
+2. **High Availability**: Cloud service providers offer redundancy and automated backup solutions to ensure high availability and minimize downtime.
+
+3. **Ease of Management**: Cloud-based deployments come with various tools and services to simplify database management tasks such as monitoring, backup, and recovery.
+
+4. **Cost Efficiency**: Cloud deployments can reduce infrastructure and maintenance costs compared to on-premises installations.
+
+## Major Cloud Providers
+
+There are several major cloud providers that offer managed PostgreSQL services:
+
+1. [**Amazon Web Services (AWS) RDS for PostgreSQL**](https://aws.amazon.com/rds/postgresql/): AWS RDS provides a fully managed PostgreSQL service with features such as automated backups, monitoring, and scaling.
+
+2. [**Google Cloud SQL for PostgreSQL**](https://cloud.google.com/sql/docs/postgres): This fully managed service from Google Cloud Platform offers high availability, automated backups, and scalability.
+
+3. [**Microsoft Azure Database for PostgreSQL**](https://azure.microsoft.com/en-us/services/postgresql/): Azure's managed PostgreSQL service comes with built-in high availability, automated backups, and automatic scaling.
+
+4. [**IBM Cloud Databases for PostgreSQL**](https://www.ibm.com/cloud/databases-for-postgresql): IBM Cloud provides a fully managed PostgreSQL service with high availability, automated backups, and easy scaling.
+
+5. [**Aiven for PostgreSQL**](https://aiven.io/postgresql): Aiven offers a managed PostgreSQL service with various features including high availability, automated backups, and scaling across multiple cloud providers.
+
+## Deployment Process
+
+The deployment process for PostgreSQL in the cloud typically involves the following steps:
+
+1. **Choose a Cloud Service Provider:** Select a cloud provider that best meets your needs in terms of functionality, reliability, and cost. Each provider has its unique offerings, so conduct a thorough evaluation based on your requirements.
+
+2. **Create an Instance:** Once you have chosen a provider, create a new PostgreSQL instance through the provider's management console or API. Specify the required parameters such as instance size, region, and storage capacity. Some cloud providers also support the creation of read replicas for load balancing and high availability.
+
+3. **Configure Security:** Secure your PostgreSQL instance by configuring firewall rules, SSL certificates, and authentication settings. Ensure that only authorized users and applications can access your database.
+
+4. **Migrate Data:** If you are migrating an existing PostgreSQL database to the cloud, you will need to transfer your data. Use tools such as `pg_dump` and `pg_restore` or cloud-native migration services offered by your chosen provider.
+
+5. **Monitor and Optimize:** Once your PostgreSQL instance is up and running, monitor its performance using the tools provided by the cloud service. Optimize the database by scaling resources, indexing, and query optimization based on the observed performance metrics.
+
+By deploying PostgreSQL in the cloud, you can leverage the advantages of flexibility, scalability, and cost-efficiency that cloud environments offer. As a PostgreSQL DBA, familiarize yourself with the various cloud providers and their services to make informed decisions on which platform best suits your deployment needs.

src/data/roadmaps/postgresql-dba/content/103-installation-and-setup/104-using-systemd.md

@@ -1 +1,63 @@
-# Using systemd
+# Using `systemd`
+
+## Using Systemd for PostgreSQL
+
+Systemd is an init-based system manager for Linux that provides a standardized way of managing system processes. It is commonly used for starting, stopping, and controlling processes such as PostgreSQL, which can be installed as a service. In this section, we will explore how to manage PostgreSQL using systemd.
+
+### Installing PostgreSQL with systemd
+
+When installing PostgreSQL through various package managers (e.g., `apt` or `yum`), the installation process will typically configure the service to run using systemd. The PostgreSQL service should *not* be started manually. Instead, we control the service using systemd commands.
+
+### Start and Stop PostgreSQL via systemd
+
+To start PostgreSQL using systemd, run the following command:
+
+```
+sudo systemctl start postgresql
+```
+
+To stop PostgreSQL using systemd, run the following command:
+
+```
+sudo systemctl stop postgresql
+```
+
+### Enable and Disable PostgreSQL auto-start
+
+To enable PostgreSQL to start automatically with the system, run the command:
+
+```
+sudo systemctl enable postgresql
+```
+
+To disable PostgreSQL auto-start, run the command:
+
+```
+sudo systemctl disable postgresql
+```
+
+### Check the PostgreSQL service status
+
+To check the status of the PostgreSQL service, use the following command:
+
+```
+sudo systemctl status postgresql
+```
+
+This command will show whether the PostgreSQL service is running, stopped or failed, and display relevant log messages from systemd journal.
+
+### Configuration and Log files
+
+Systemd manages the PostgreSQL service using a unit configuration file, typically located at `/etc/systemd/system/postgresql.service` or `/lib/systemd/system/postgresql.service`. It provides a standard way of defining how the PostgreSQL service is started, stopped, and restarted.
+
+PostgreSQL log files can be accessed using the journalctl command:
+
+```
+sudo journalctl -u postgresql --since "YYYY-MM-DD HH:MM:SS"
+```
+
+Replace the "YYYY-MM-DD HH:MM:SS" with the desired date and time to view logs since that specific time.
+
+### Conclusion
+
+Systemd provides a convenient and standardized approach to managing the PostgreSQL service on Linux. Understanding how to interact with the PostgreSQL service through systemd commands will help you efficiently manage your PostgreSQL installation and troubleshoot issues when they arise.

src/data/roadmaps/postgresql-dba/content/103-installation-and-setup/105-using-pgctl.md

@@ -1 +1,53 @@
-# Using pgctl
+# Using `pg_ctl`
+
+## Using `pg_ctl`
+
+`pg_ctl` is a utility for managing PostgreSQL server processes. This tool allows you to start, stop, restart, and check the status of your PostgreSQL server. In this section, we will cover the basic usage of `pg_ctl` and some common scenarios where it is helpful.
+
+### Starting the PostgreSQL server
+
+To start the PostgreSQL server, you can use the following command:
+
+```
+pg_ctl start -D /path/to/your/data/directory
+```
+
+Here, the `-D` flag specifies the location of your PostgreSQL data directory, which contains various configuration files and the database itself.
+
+### Stopping the PostgreSQL server
+
+To stop a running PostgreSQL server, use the following command:
+
+```
+pg_ctl stop -D /path/to/your/data/directory
+```
+
+### Restarting the PostgreSQL server
+
+If you need to restart the server for any reason, such as applying new configuration changes, you can use the restart command:
+
+```
+pg_ctl restart -D /path/to/your/data/directory
+```
+
+### Checking the server status
+
+To check the status of your PostgreSQL server, use the status command:
+
+```
+pg_ctl status -D /path/to/your/data/directory
+```
+
+This command will display whether the server is running, its process ID (PID), and the location of the data directory.
+
+### Additional options
+
+`pg_ctl` offers additional options, such as controlling the wait time before stopping the server, or even running a new instance with a different configuration file. You can find the full list of options by running:
+
+```
+pg_ctl --help
+```
+
+### Summary
+
+`pg_ctl` is a valuable tool for managing PostgreSQL server instances. It helps you start, stop, restart, and check the status of your PostgreSQL server easily. Familiarizing yourself with its usage will make your job easier as a PostgreSQL DBA.

src/data/roadmaps/postgresql-dba/content/103-installation-and-setup/106-using-pgctlcluster.md

@@ -1 +1,54 @@
-# Using pgctlcluster
+# Using `pg_ctlcluster`
+
+## Using pg_ctlcluster
+_pg_ctlcluster_ is a utility for managing and controlling your PostgreSQL clusters. This section will cover the most commonly used options for the _pg_ctlcluster_ command.
+
+### Starting a PostgreSQL Cluster
+To start a cluster, you should provide the version, cluster name, and the `start` option:
+```
+pg_ctlcluster <version> <cluster_name> start
+```
+For example, to start a cluster with version 11 and named "main":
+```
+pg_ctlcluster 11 main start
+```
+
+### Stopping a PostgreSQL Cluster
+To stop a cluster, simply replace the `start` option with `stop` in the previous command:
+```
+pg_ctlcluster <version> <cluster_name> stop
+```
+
+### Restarting a PostgreSQL Cluster
+If you need to restart a cluster, you can use the `restart` option:
+```
+pg_ctlcluster <version> <cluster_name> restart
+```
+
+### Viewing PostgreSQL Cluster Status
+To check the status of your PostgreSQL cluster, use the `status` option:
+```
+pg_ctlcluster <version> <cluster_name> status
+```
+
+### Managing Cluster Logs
+By default, the `pg_ctlcluster` logs are stored in the `/var/log/postgresql` directory, with the file named `postgresql-<version>-<cluster_name>.log`. You can view logs in real-time using the `tail` command:
+```
+tail -f /var/log/postgresql/postgresql-<version>-<cluster_name>.log
+```
+
+### Custom Configuration Files
+_pg_ctlcluster_ allows specifying custom configuration files with the `--config-file` and `--hba-file` options.
+
+* Use `--config-file` to point to a custom postgresql.conf file:
+  ```
+  pg_ctlcluster <version> <cluster_name> start --config-file=<path_to_custom_conf>
+  ```
+
+* Use `--hba-file` to point to a custom pg_hba.conf file:
+  ```
+  pg_ctlcluster <version> <cluster_name> start --hba-file=<path_to_custom_pg_hba_conf>
+  ```
+
+### Conclusion
+_pg_ctlcluster_ is a powerful utility to manage PostgreSQL clusters. This guide covered the most commonly used options, such as starting, stopping, and restarting clusters. Additionally, it reviewed checking cluster status, viewing logs, and specifying custom configuration files. With these commands in hand, you'll be well-equipped to manage your PostgreSQL clusters effectively.

src/data/roadmaps/postgresql-dba/content/103-installation-and-setup/index.md

@@ -1 +1,53 @@
-# Installation and setup
+# Installation and Setup
+
+# Installation and Setup
+
+This chapter focuses on the installation and setup process of PostgreSQL as a Database Administrator (DBA). PostgreSQL is a powerful and robust open-source database system that can be installed on various platforms such as Windows, macOS, and Linux.
+
+## Prerequisites
+
+Before starting the installation, ensure that your system meets the hardware and software requirements. Moreover, some basic knowledge of networking will be helpful for configuring the PostgreSQL server.
+
+## Choose a Platform
+
+PostgreSQL is supported on various operating systems, like:
+
+- Windows
+- macOS
+- Linux distributions (such as Ubuntu, CentOS, and more)
+
+Choose the platform that best suits your requirements and is compatible with the application you are planning to develop.
+
+## Download and Install
+
+Download the PostgreSQL installer from the [official website](https://www.postgresql.org/download/). Select the appropriate platform and version, then proceed with the installation process.
+
+### Windows
+
+Run the downloaded installer and follow the on-screen instructions. The installer will take care of installing all necessary components, such as the PostgreSQL server, command-line utilities, pgAdmin, Stack Builder, and documentation.
+
+### macOS
+
+Download the macOS installer and follow the steps provided in the installer's README. The macOS installer will install the PostgreSQL server, command-line utilities, and pgAdmin.
+
+### Linux
+
+For Linux, package managers like `apt-get` (for Debian-based distributions) or `yum` (for Red Hat-based distributions) can be used to install PostgreSQL. Follow the instructions on the official website for detailed steps to install PostgreSQL on your Linux distribution.
+
+## Initial Configuration
+
+After installation, it is essential to configure several aspects of the PostgreSQL server to ensure proper functioning and security. Some key configurations include:
+
+1. **Assigning the data directory (`data_directory`):** You must set the data directory in `postgresql.conf` to the location where you want to store the database files.
+
+2. **Configure network settings:** You need to configure the listen address, port number, and client authentication by modifying the `listen_address`, `port`, and `hba_file` parameters in `postgresql.conf` and `pg_hba.conf`.
+
+3. **Setting up user access:** Create a dedicated PostgreSQL user and set proper access permissions for the database.
+
+## Start and Test the Server
+
+Once the configuration is complete, start the PostgreSQL server using the appropriate commands for your platform. You can then test the connection using a suitable client, like `psql` or pgAdmin.
+
+## Summary
+
+In this chapter, we covered the installation and setup process for PostgreSQL on Windows, macOS, and Linux platforms. It is crucial to properly configure the server according to your requirements for smooth operation and security. In the next chapters, we will delve deeper into database management, monitoring, and optimization.

src/data/roadmaps/postgresql-dba/content/104-learn-sql-concepts/100-ddl-queries/100-for-schemas.md

@@ -1 +1,75 @@
-# For schemas
+# For Schemas
+
+# Managing Schemas in PostgreSQL
+
+In this section, we will discuss schemas in PostgreSQL and how you can manage them using Data Definition Language (DDL) queries. Schemas provide a way to organize and compartmentalize database objects such as tables, views, and functions in PostgreSQL. They offer a logical separation of database objects, allowing you to manage access permissions and application specific code more effectively. 
+
+## What is a Schema?
+
+A schema in PostgreSQL is essentially a namespace that enables you to group database objects into separate, manageable groups. Schemas can be thought of as folders that help you structure and organize your database more efficiently.
+
+Some of the key benefits of using schemas include:
+
+1. Improved organization and management of database objects.
+2. Better separation of concerns between applications and developers.
+3. Enhanced security by controlling access to specific schema objects.
+
+## DDL Queries for Schemas
+
+In this section, we'll go over various DDL queries that are used to manage schemas in PostgreSQL.
+
+### Creating a Schema
+
+To create a new schema, you can use the `CREATE SCHEMA` statement. The basic syntax is as follows:
+
+```sql
+CREATE SCHEMA schema_name;
+```
+
+Here's an example that creates a schema named `orders`:
+
+```sql
+CREATE SCHEMA orders;
+```
+
+### Listing Schemas
+
+To view a list of all available schemas in your database, you can query the `pg_namespace` system catalog table. Here's an example:
+
+```sql
+SELECT nspname FROM pg_namespace;
+```
+
+### Renaming a Schema
+
+To rename an existing schema, you can use the `ALTER SCHEMA` statement along with the `RENAME TO` clause. The basic syntax is as follows:
+
+```sql
+ALTER SCHEMA old_schema_name RENAME TO new_schema_name;
+```
+
+Here's an example that renames the `orders` schema to `sales`:
+
+```sql
+ALTER SCHEMA orders RENAME TO sales;
+```
+
+### Dropping a Schema
+
+To remove a schema along with all of its objects, you can use the `DROP SCHEMA` statement with the `CASCADE` option. The basic syntax is as follows:
+
+```sql
+DROP SCHEMA schema_name CASCADE;
+```
+
+Here's an example that drops the `sales` schema and all its associated objects:
+
+```sql
+DROP SCHEMA sales CASCADE;
+```
+
+**Note:** Be cautious when using the `CASCADE` option, as it will remove the schema and all its related objects, including tables and data.
+
+## Conclusion
+
+In this section, we covered the concept of schemas in PostgreSQL and how they can be managed using DDL queries. Understanding and effectively managing schemas can lead to a better-organized database, improved separation of concerns, and enhanced security.

src/data/roadmaps/postgresql-dba/content/104-learn-sql-concepts/100-ddl-queries/101-for-tables.md

@@ -1 +1,97 @@
-# For tables
+# For Tables
+
+# DDL Queries for Tables
+
+In this section, we'll explore Data Definition Language (DDL) queries specifically for tables in PostgreSQL. These are the queries that allow you to create, alter, and remove tables from the database.
+
+## Creating Tables
+
+To create a new table, you'll use the CREATE TABLE command. This command requires a table name and a list of column definitions:
+
+```sql
+CREATE TABLE table_name (
+  column1 data_type [constraints],
+  column2 data_type [constraints],
+  ...
+);
+```
+
+For example, to create a table named `employees` with three columns (id, name, and department), you'd use the following query:
+
+```sql
+CREATE TABLE employees (
+  id SERIAL PRIMARY KEY,
+  name VARCHAR(100) NOT NULL,
+  department VARCHAR(50) NOT NULL
+);
+```
+
+In this example, the `id` column is of type SERIAL, which is an auto-incrementing integer, and it also serves as the primary key for the table. The `name` and `department` columns are of type VARCHAR with specific length constraints.
+
+## Altering Tables
+
+You can use the ALTER TABLE command to modify an existing table, such as adding, renaming, or removing columns or constraints. Here are some common queries:
+
+### Adding a Column
+
+To add a new column to an existing table, use the following syntax:
+
+```sql
+ALTER TABLE table_name
+ADD COLUMN column_name data_type [constraints];
+```
+
+For example, to add a `salary` column to the `employees` table, you'd use this query:
+
+```sql
+ALTER TABLE employees
+ADD COLUMN salary DECIMAL(10, 2);
+```
+
+### Renaming a Column
+
+To rename an existing column, use the following syntax:
+
+```sql
+ALTER TABLE table_name
+RENAME COLUMN old_column_name TO new_column_name;
+```
+
+For example, to rename the `department` column to `dept`:
+
+```sql
+ALTER TABLE employees
+RENAME COLUMN department TO dept;
+```
+
+### Removing a Column
+
+To remove a column from a table, use the following syntax:
+
+```sql
+ALTER TABLE table_name
+DROP COLUMN column_name CASCADE;
+```
+
+For example, to remove the `salary` column:
+
+```sql
+ALTER TABLE employees
+DROP COLUMN salary CASCADE;
+```
+
+## Removing Tables
+
+To remove a table from the database, use the DROP TABLE command. Be cautious when using this command, as it permanently deletes the table and all its data:
+
+```sql
+DROP TABLE table_name [CASCADE];
+```
+
+For example, to remove the `employees` table and all its dependencies:
+
+```sql
+DROP TABLE employees CASCADE;
+```
+
+In conclusion, DDL queries for tables allow you to manage the structure of your PostgreSQL database effectively. Understanding how to create, alter, and remove tables is essential as you progress in your role as a PostgreSQL DBA.

src/data/roadmaps/postgresql-dba/content/104-learn-sql-concepts/100-ddl-queries/102-data-types.md

@@ -1 +1,72 @@
-# Data types
+# Data Types
+
+# Data Types in PostgreSQL
+
+In PostgreSQL, a Data Type defines the type of data that can be stored in a column. Understanding data types is essential for designing your database schema and ensuring the correct storage and retrieval of data. In this section, we'll cover some of the most common data types in PostgreSQL.
+
+## Numeric Data Types
+
+PostgreSQL supports several numeric data types for integers and floating-point numbers.
+
+### Integer Data Types
+
+- **Small Integer (smallint):** Stores whole numbers ranging from -32,768 to 32,767, occupying 2 bytes of storage.
+- **Integer (integer/int):** Stores whole numbers ranging from -2,147,483,648 to 2,147,483,647, occupying 4 bytes of storage.
+- **Big Integer (bigint):** Stores whole numbers ranging from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807, occupying 8 bytes of storage.
+
+### Floating-Point Data Types
+
+- **Real (real/float4):** Stores floating-point numbers with 6 decimal digits precision, occupying 4 bytes of storage.
+- **Double Precision (double precision/float8):** Stores floating-point numbers with 15 decimal digits precision, occupying 8 bytes of storage.
+- **Numeric (numeric/decimal):** Stores exact numeric values with user-defined precision up to 131,072 digits and 16,383 decimals, occupying variable storage.
+
+## Character Data Types
+
+PostgreSQL provides several types of textual data types to store strings of varying lengths.
+
+- **Character Varying (varchar(n)):** Stores strings of variable length with a user-defined maximum length of `n` characters. If not specified, the length is unlimited.
+- **Character (char(n)):** Stores fixed-length strings of exactly `n` characters. If the input string is shorter, it gets padded with spaces.
+- **Text (text):** Stores strings of variable length with no limit.
+
+## Date and Time Data Types
+
+PostgreSQL offers various data types for date and time information management.
+
+- **Date (date):** Stores only the date with no time data.
+- **Time (time [without time zone]):** Stores time without any date or timezone data.
+- **Timestamp (timestamp [without time zone]):** Stores both date and time without timezone data.
+- **Time with Time Zone (time [with time zone] / timestamptz):** Stores both date and time with timezone data.
+
+## Boolean Data Type
+
+- **Boolean (boolean/bool):** Stores either true, false, or null values.
+
+## Enumerated Data Type
+
+- **Enum (enum):** Stores a predefined static, ordered set of values. You must create the enum type before using it.
+
+## UUID Data Type
+
+- **UUID (uuid):** Stores universally unique identifiers (UUIDs) represented as 32 hexadecimal characters (16 bytes).
+
+## JSON Data Types
+
+PostgreSQL provides two data types for storing JSON data.
+
+- **JSON (json):** Stores JSON data in a flexible format, allowing arbitrary queries and manipulation.
+- **JSONB (jsonb):** Stores JSON data in a binary format, offering faster query performance compared to JSON.
+
+## Array Data Type
+
+- **Array (any_array):** Stores an ordered collection of data of the same data type. You can define arrays for any supported data type.
+
+## Special Data Types
+
+PostgreSQL offers some special data types that are worth mentioning:
+
+- **Interval (interval):** Represents a time duration.
+- **Bit (bit(n)):** Stores a fixed-length bit string of size `n`.
+- **Bit Varying (bit varying(n)/varbit(n)):** Stores a variable-length bit string with a user-defined maximum length of `n`.
+- **Serial Types (serial, smallserial, bigserial):** Used for auto-incrementing integer columns.
+
+Understanding data types is crucial to creating efficient and accurate database schemas in PostgreSQL. Be sure to choose the appropriate data type for each column to ensure the best possible performance and data validation.

src/data/roadmaps/postgresql-dba/content/104-learn-sql-concepts/100-ddl-queries/index.md

@@ -1 +1,68 @@
-# Ddl queries
+# DDL Queries
+
+### DDL Queries
+
+In this section, we'll discuss DDL (Data Definition Language) queries in PostgreSQL. DDL queries are responsible for defining or manipulating the database table schema, like creating, altering, or deleting tables, columns, indexes, and other database objects.
+
+#### CREATE TABLE
+
+The `CREATE TABLE` statement is used to create a new table with a defined schema. This query specifies the column names, data types, and any constraints that should be applied to the table.
+
+```sql
+CREATE TABLE users (
+  id SERIAL PRIMARY KEY,
+  first_name VARCHAR(100) NOT NULL,
+  last_name VARCHAR(100) NOT NULL,
+  email VARCHAR(255) UNIQUE NOT NULL,
+  created_at TIMESTAMP NOT NULL
+);
+```
+
+#### ALTER TABLE
+
+The `ALTER TABLE` statement is used to modify the structure of an existing table. You can use it to add, modify, or delete columns, as well as add or drop constraints.
+
+-- Add a new column:
+```sql
+ALTER TABLE users
+ADD COLUMN phone VARCHAR(20);
+```
+
+-- Modify an existing column:
+```sql
+ALTER TABLE users
+ALTER COLUMN email TYPE VARCHAR(200);
+```
+
+-- Drop a column:
+```sql
+ALTER TABLE users
+DROP COLUMN phone;
+```
+
+#### DROP TABLE
+
+The `DROP TABLE` statement is used to delete a table and all its data permanently from the database.
+
+```sql
+DROP TABLE users;
+```
+
+#### CREATE INDEX
+
+Indexes can speed up query executions by providing a more efficient way to look up data. The `CREATE INDEX` statement is used to create an index on a specific column.
+
+```sql
+CREATE INDEX users_email_index
+ON users (email);
+```
+
+#### DROP INDEX
+
+The `DROP INDEX` statement is used to delete an index.
+
+```sql
+DROP INDEX users_email_index;
+```
+
+In summary, DDL queries help in creating and managing database schema, creating, altering, and deleting tables and other database objects, and managing indexes for optimal performance. Remember that changes made using DDL queries are permanent, so be cautious when executing these statements.

src/data/roadmaps/postgresql-dba/content/104-learn-sql-concepts/101-dml-queries/100-querying-data.md

@@ -1 +1,132 @@
-# Querying data
+# Querying Data
+
+# Querying Data
+
+In this section, we will discuss how to query data in PostgreSQL using Data Manipulation Language (DML) queries. These queries allow you to manipulate the data within the database, such as retrieving, inserting, updating, and deleting records. Understanding these queries is essential for every PostgreSQL Database Administrator.
+
+## SELECT Statement
+
+The `SELECT` statement is the most basic and widely-used DML query for retrieving data from one or more tables. The basic syntax of the `SELECT` statement is as follows:
+
+```sql
+SELECT column1, column2, ...
+FROM table_name
+WHERE condition;
+```
+
+- `column1, column2, ...`: A comma-separated list of columns to retrieve from the table.
+- `table_name`: The name of the table you want to query.
+- `condition` (optional): A filter to apply on the records to limit the result set.
+
+### Examples
+
+1. Retrieve all columns from the "employees" table:
+
+```sql
+SELECT * FROM employees;
+```
+
+2. Retrieve "id", "name", and "salary" columns from the "employees" table:
+
+```sql
+SELECT id, name, salary FROM employees;
+```
+
+3. Retrieve "id" and "name" columns from the "employees" table with a condition: only employees with a salary greater than 50000:
+
+```sql
+SELECT id, name FROM employees
+WHERE salary > 50000;
+```
+
+## JOIN Operation
+
+When you need to fetch data from more than one table having a relationship between them, you can use the `JOIN` operation. The basic syntax of the `JOIN` operation is as follows:
+
+```sql
+SELECT column1, column2, ...
+FROM table1
+JOIN table2
+ON table1.column = table2.column
+WHERE condition;
+```
+
+- `table1` and `table2`: The two tables you want to join based on a common column.
+- `table1.column = table2.column`: A condition that specifies the link between the tables.
+
+### Examples
+
+1. Retrieve employee names and their department names, given the "employees" table has a "department_id" column and the "departments" table has "id" and "name" columns:
+
+```sql
+SELECT employees.name AS employee_name, departments.name AS department_name
+FROM employees
+JOIN departments
+ON employees.department_id = departments.id;
+```
+
+## INSERT Statement
+
+The `INSERT` statement is used to add new records to a table. The basic syntax of the `INSERT` statement is as follows:
+
+```sql
+INSERT INTO table_name (column1, column2, ...)
+VALUES (value1, value2, ...);
+```
+
+- `column1, column2, ...`: A comma-separated list of columns that you want to insert values into.
+- `value1, value2, ...`: A comma-separated list of values that correspond to the specified columns.
+
+### Example
+
+1. Insert a new employee into the "employees" table:
+
+```sql
+INSERT INTO employees (name, age, salary, department_id)
+VALUES ('John Doe', 30, 55000, 1);
+```
+
+## UPDATE Statement
+
+The `UPDATE` statement is used to modify existing records in a table. The basic syntax of the `UPDATE` statement is as follows:
+
+```sql
+UPDATE table_name
+SET column1 = value1, column2 = value2, ...
+WHERE condition;
+```
+
+- `column1 = value1, column2 = value2, ...`: A comma-separated list of column-value pairs that indicate the changes to be made.
+- `condition` (optional): A filter to apply on the records to limit the updates.
+
+### Example
+
+1. Update the salary of an employee with an "id" of 3:
+
+```sql
+UPDATE employees
+SET salary = 60000
+WHERE id = 3;
+```
+
+## DELETE Statement
+
+The `DELETE` statement is used to remove records from a table. The basic syntax of the `DELETE` statement is as follows:
+
+```sql
+DELETE FROM table_name
+WHERE condition;
+```
+
+- `condition` (optional): A filter to apply on the records to limit the deletions. If not provided, all records in the table will be deleted.
+
+### Example
+
+1. Delete an employee with an "id" of 5 from the "employees" table:
+
+```sql
+DELETE FROM employees
+WHERE id = 5;
+```
+
+In summary, DML queries are essential for managing and manipulating data in PostgreSQL databases. Mastering these queries and understanding the underlying principles is a crucial skill for any PostgreSQL Database Administrator.

src/data/roadmaps/postgresql-dba/content/104-learn-sql-concepts/101-dml-queries/101-filtering-data.md

@@ -1 +1,111 @@
-# Filtering data
+# Filtering Data
+
+## Filtering Data in PostgreSQL
+
+Filtering data in PostgreSQL allows you to selectively retrieve records from your tables based on specified conditions. This is a fundamental aspect of database management as it helps in returning only relevant records for a specific query. In this section, we will discuss how to use various filtering techniques in PostgreSQL.
+
+### WHERE Clause
+
+The `WHERE` clause is the most basic way to filter data in PostgreSQL. It is used to specify the conditions that must be met for a record to be included in the result set. The syntax for the `WHERE` clause is:
+
+```sql
+SELECT column1, column2, ...
+FROM table
+WHERE condition;
+```
+
+The `condition` can be any expression that evaluates to a boolean value (`true` or `false`). If the condition is `true` for a record, it will be included in the result set. 
+
+Here's an example:
+
+```sql
+SELECT first_name, last_name, age
+FROM users
+WHERE age >= 18;
+```
+
+This query will return all records from the `users` table where the `age` is greater than or equal to 18.
+
+### AND, OR and NOT Operators
+
+You can use the logical operators `AND`, `OR`, and `NOT` to combine multiple conditions in your `WHERE` clause. 
+
+- The `AND` operator returns `true` if both conditions are true. Example:
+
+  ```sql
+  SELECT first_name, last_name, age
+  FROM users
+  WHERE age >= 18 AND city = 'New York';
+  ```
+
+- The `OR` operator returns `true` if at least one of the conditions is true. Example:
+
+  ```sql
+  SELECT first_name, last_name, age
+  FROM users
+  WHERE age <= 18 OR city = 'New York';
+  ```
+
+- The `NOT` operator negates a condition. Example:
+
+  ```sql
+  SELECT first_name, last_name, age
+  FROM users
+  WHERE NOT city = 'New York';
+  ```
+
+### USING Comparison Operators
+
+PostgreSQL supports several comparison operators that you can use in your `WHERE` clause to filter data. These include:
+
+- `= (equal)`
+- `<> or != (not equal)`
+- `< (less than)`
+- `> (greater than)`
+- `<= (less than or equal to)`
+- `>= (greater than or equal to)`
+
+You can also use `LIKE` and `ILIKE` operators to filter records based on pattern matching with wildcard characters:
+
+- `% (percent)` represents zero, one or multiple characters.
+- `_ (underscore)` represents a single character.
+
+Example:
+
+```sql
+SELECT first_name, last_name, email
+FROM users
+WHERE email LIKE '%@example.com';
+```
+
+This query will return all records where the email address ends with '@example.com'.
+
+### IN, BETWEEN, and NULL
+
+You can also use `IN`, `BETWEEN`, and `NULL` operators to filter data:
+
+- `IN` operator checks if a value is within a set of values. Example:
+
+  ```sql
+  SELECT first_name, last_name, city
+  FROM users
+  WHERE city IN ('New York', 'Los Angeles', 'Chicago');
+  ```
+
+- `BETWEEN` operator checks if a value is within a specific range. Example:
+
+  ```sql
+  SELECT first_name, last_name, age
+  FROM users
+  WHERE age BETWEEN 18 AND 25;
+  ```
+
+- `IS NULL` or `IS NOT NULL` operators checks if a value is null or not. Example:
+
+  ```sql
+  SELECT first_name, last_name, phone
+  FROM users
+  WHERE phone IS NULL;
+  ```
+
+By using these filtering techniques, you can customize your DML queries to return only the data that meets your specific criteria. This is essential for managing large datasets and optimizing the performance of your PostgreSQL database.

src/data/roadmaps/postgresql-dba/content/104-learn-sql-concepts/101-dml-queries/102-modifying-data.md

@@ -1 +1,51 @@
-# Modifying data
+# Modifying Data
+
+## Modifying Data in PostgreSQL
+
+In PostgreSQL, modifying data is done through the use of Data Manipulation Language (DML) queries. It is an essential part of managing and maintaining any database system. In this topic, we will cover three types of DML queries that are important for modifying data in PostgreSQL: `INSERT`, `UPDATE`, and `DELETE`.
+
+### 1. INSERT
+
+The `INSERT` statement is used to add new rows into a table. The basic syntax for the statement is as follows:
+
+```sql
+INSERT INTO table_name (column1, column2, ...) VALUES (value1, value2, ...);
+```
+
+For example, let's say we have a table named `employees` with columns `id`, `name`, and `salary`. To add a new employee into this table, we can execute the following query:
+
+```sql
+INSERT INTO employees (id, name, salary) VALUES (1, 'John Doe', 50000);
+```
+
+### 2. UPDATE
+
+The `UPDATE` statement is used to modify the data of one or more rows in a table. The basic syntax for the command is as follows:
+
+```sql
+UPDATE table_name SET column1 = value1, column2 = value2, ... WHERE condition;
+```
+
+Make sure to include the correct `WHERE` clause to specify which rows you'd like to update. For example, to increase the salary of an employee with the `id` equal to `1`, we can execute the following query:
+
+```sql
+UPDATE employees SET salary = salary + 5000 WHERE id = 1;
+```
+
+### 3. DELETE
+
+The `DELETE` statement is used to remove one or more rows from a table. Be careful when using this statement, as any deleted data cannot be easily recovered. The basic syntax for the command is as follows:
+
+```sql
+DELETE FROM table_name WHERE condition;
+```
+
+For example, to remove an employee with the `id` equal to `1`, we can execute the following query:
+
+```sql
+DELETE FROM employees WHERE id = 1;
+```
+
+---
+
+In conclusion, modifying data in a PostgreSQL database is an important responsibility for any database administrator. Mastery of DML queries such as `INSERT`, `UPDATE`, and `DELETE` is essential for managing and maintaining the data in your database. Remember to be cautious when using these queries, especially `DELETE`, to avoid unintentional data loss or corruption.

src/data/roadmaps/postgresql-dba/content/104-learn-sql-concepts/101-dml-queries/103-joining-tables.md

@@ -1 +1,61 @@
-# Joining tables
+# Joining Tables
+
+## Joining Tables
+
+Joining tables is a fundamental concept in SQL databases, as it allows you to combine data from two or more tables based on a related column. In PostgreSQL, there are several types of joins that can be used to retrieve data from multiple tables, such as Inner Join, Left Join, Right Join, Full Outer Join, and Cross Join.
+
+### Inner Join
+
+An inner join returns rows from both tables that satisfy the given condition. It combines the columns of both tables where the specified condition is met. The syntax for inner join is:
+
+```sql
+SELECT columns
+FROM table1
+JOIN table2
+ON table1.column = table2.column;
+```
+
+### Left Join (Left Outer Join)
+
+A left join returns all rows from the left table (table1) and the matched rows from the right table (table2). If no match is found, NULL values are returned for the right table's columns. The syntax for left join is:
+
+```sql
+SELECT columns
+FROM table1
+LEFT JOIN table2
+ON table1.column = table2.column;
+```
+
+### Right Join (Right Outer Join)
+
+A right join returns all rows from the right table (table2) and the matched rows from the left table (table1). If no match is found, NULL values are returned for the left table's columns. The syntax for right join is:
+
+```sql
+SELECT columns
+FROM table1
+RIGHT JOIN table2
+ON table1.column = table2.column;
+```
+
+### Full Outer Join
+
+A full outer join returns all rows from both tables, with NULL values in columns where there's no match between the rows. The syntax for full outer join is:
+
+```sql
+SELECT columns
+FROM table1
+FULL OUTER JOIN table2
+ON table1.column = table2.column;
+```
+
+### Cross Join
+
+A cross join returns the Cartesian product of both tables, which means it combines each row from the first table with every row of the second table. This type of join doesn't require a condition as it returns all possible combinations. The syntax for cross join is:
+
+```sql
+SELECT columns
+FROM table1
+CROSS JOIN table2;
+```
+
+In conclusion, joining tables is an essential technique to combine data from different tables based on common columns. With various types of joins available in PostgreSQL, you can utilize them to get the desired information efficiently.

src/data/roadmaps/postgresql-dba/content/104-learn-sql-concepts/101-dml-queries/index.md

@@ -1 +1,57 @@
-# Dml queries
+# DML Queries
+
+## DML Queries
+
+Data Manipulation Language (DML) queries refer to the set of SQL statements that allow you to interact with your database data. DML queries enable you to perform basic operations such as inserting, updating, and retrieving information from your database. These queries are essential for any PostgreSQL DBA, as they are the foundation of interacting with the data stored in your system.
+
+In this section, we will go over the fundamental DML queries and provide examples on how to use each one.
+
+### SELECT
+
+The `SELECT` statement is used to query and retrieve data from your database. It allows you to fetch data from one or more tables and filter, sort, or group the results according to your requirements.
+
+Here's a simple example of a `SELECT` query:
+
+```sql
+SELECT first_name, last_name FROM employees;
+```
+
+This query retrieves the `first_name` and `last_name` columns from the `employees` table.
+
+### INSERT
+
+The `INSERT` statement is used to add new rows to a table. You can specify which columns the data should be inserted into, and provide the corresponding values.
+
+For example, to add a new employee record to a table, you would use the following query:
+
+```sql
+INSERT INTO employees (first_name, last_name, hire_date) VALUES ('John', 'Doe', '2022-01-01');
+```
+
+This query inserts a new row in the `employees` table with the values provided for the `first_name`, `last_name`, and `hire_date` columns.
+
+### UPDATE
+
+The `UPDATE` statement is used to modify existing data in your database. With this statement, you can change the values of specified columns for all rows that meet a certain condition.
+
+Here's an example of an `UPDATE` query:
+
+```sql
+UPDATE employees SET salary = salary * 1.1 WHERE last_name = 'Doe';
+```
+
+This query updates the `salary` column by increasing the current value by 10% for all employees with the last name 'Doe'.
+
+### DELETE
+
+The `DELETE` statement allows you to remove rows from a table based on specified conditions.
+
+For example, if you wanted to delete all records of employees hired before 2022, you would use the following query:
+
+```sql
+DELETE FROM employees WHERE hire_date < '2022-01-01';
+```
+
+This query deletes all rows from the `employees` table where the `hire_date` is earlier than January 1, 2022.
+
+In conclusion, DML queries are the cornerstone of any PostgreSQL DBA's toolkit. Familiarizing yourself with them is essential for managing and interacting with your database effectively.

src/data/roadmaps/postgresql-dba/content/104-learn-sql-concepts/102-import-export-using-copy.md

@@ -1 +1,48 @@
-# Import export using copy
+# Import / Export using `COPY`
+
+## Import Export using COPY in PostgreSQL
+
+The `COPY` command in PostgreSQL provides a simple and efficient way to import and export data between a CSV (Comma Separated Values) file and a PostgreSQL database. It is an essential tool for any PostgreSQL DBA who wants to move data between different systems or quickly load large datasets.
+
+### Import Data using COPY
+
+To import data from a CSV file into a PostgreSQL table, you can use the following syntax:
+
+```sql
+COPY <table_name> (column1, column2, column3, ...)
+FROM '<file_path>'
+WITH (FORMAT csv, HEADER, DELIMITER ',', NULL '<null_value>', QUOTE '"', ESCAPE '\"', ENCODING '<encoding>');
+```
+
+- `<table_name>`: The name of the table that you want to import the data into.
+- `(column1, column2, column3, ...)` : Specify the list of columns in the table that you want to populate with the data from the CSV.
+- `<file_path>`: The path to the CSV file.
+- `FORMAT csv`: Specifies that the file is in CSV format.
+- `HEADER`: Indicates that the first line of the file contains the column names for the dataset, omit this if there's no header.
+- `DELIMITER ','`: Specifies the character used to separate the fields in the CSV file (comma by default).
+- `NULL '<null_value>'`: Specifies the string that represents a `NULL` value in the CSV file (empty string by default).
+- `QUOTE '"'` : Specifies the character used to represent text data (double quote by default).
+- `ESCAPE '\"'` : Specifies the character used to escape any quotes within text data (double quote by default).
+- `ENCODING '<encoding>'`: Specifies the character encoding of the file (default is the server's encoding).
+
+### Export Data using COPY
+
+To export data from a PostgreSQL table to a CSV file, you can use the following syntax:
+
+```sql
+COPY (SELECT column1, column2, column3, ...
+      FROM <table_name>
+      WHERE ... )
+TO '<file_path>'
+WITH (FORMAT csv, HEADER, DELIMITER ',', NULL '<null_value>', QUOTE '"', ESCAPE '\"', ENCODING '<encoding>');
+```
+
+- `<table_name>`: The name of the table that you want to export the data from.
+- `SELECT column1, column2, column3, ...`: The columns that you want to export.
+- `WHERE ...`: Optional WHERE clause to filter the rows that you want to export.
+- `<file_path>`: The path where the CSV file will be created.
+- All other options are the same as in the import query.
+
+Keep in mind that the `COPY` command can only be used by a superuser or a user with the appropriate permissions. Also, the `COPY` command works only with server-side file paths, so ensure that the path is accessible by the PostgreSQL server.
+
+In case you want to import/export data using client-side paths or work with other formats like JSON, you can use the `\copy` meta-command in the `psql` command-line interface, which has similar syntax but works with client-side paths.

src/data/roadmaps/postgresql-dba/content/104-learn-sql-concepts/103-advanced-topics/100-transactions.md

@@ -1 +1,59 @@
-# Transactions
+# Transactions
+
+# Transactions
+
+Transactions are a crucial aspect of any database management system, and PostgreSQL is no exception. A transaction is a sequence of one or more SQL operations that constitute a single, logical unit of work. Transactions provide a consistent and reliable mechanism for safeguarding the integrity of the database when multiple operations are performed concurrently.
+
+The primary goal of a transaction is to ensure that the database remains in a consistent state despite any errors or system crashes that may occur during its operation. To achieve this goal, PostgreSQL implements a set of properties known as **ACID**:
+
+- **A**tomicity: A transaction must be either fully completed or fully rolled back. There can be no partial transactions.
+- **C**onsistency: The database must always transition from one consistent state to another upon the completion of a transaction.
+- **I**solation: Each transaction must be completely isolated from other transactions running concurrently.
+- **D**urability: Once a transaction has been committed, its changes must be permanently saved in the database.
+
+## Using Transactions in PostgreSQL
+
+To start a transaction, use the `BEGIN` statement:
+
+```sql
+BEGIN;
+```
+
+You can then execute the SQL operations that form your transaction. For example, consider a simple banking scenario where you're transferring funds from one account to another:
+
+```sql
+-- Subtract the transferred amount from the first account's balance
+UPDATE accounts SET balance = balance - 100 WHERE id = 1;
+
+-- Add the transferred amount to the second account's balance
+UPDATE accounts SET balance = balance + 100 WHERE id = 2;
+```
+
+To commit the transaction and save the changes to the database permanently, use the `COMMIT` statement:
+
+```sql
+COMMIT;
+```
+
+If an error occurs during the transaction, or you need to cancel the transaction for any reason, you can roll back the transaction using the `ROLLBACK` statement:
+
+```sql
+ROLLBACK;
+```
+
+## Transaction Isolation Levels
+
+PostgreSQL provides multiple transaction isolation levels that govern the visibility of data changes made by one transaction to other concurrent transactions. The default isolation level in PostgreSQL is **Read Committed**. Other isolation levels include **Read Uncommitted**, **Repeatable Read**, and **Serializable**.
+
+To set the transaction isolation level for a specific transaction, use the `SET TRANSACTION` statement:
+
+```sql
+BEGIN;
+SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
+-- Your SQL operations here
+COMMIT;
+```
+
+Understanding and selecting the appropriate transaction isolation level is essential for achieving the desired balance between data consistency and application performance.
+
+In summary, transactions are a powerful mechanism that PostgreSQL offers to ensure data consistency and integrity when executing multiple operations on the database. By understanding and effectively using transactions, you can build robust and reliable database applications.

src/data/roadmaps/postgresql-dba/content/104-learn-sql-concepts/103-advanced-topics/101-cte.md

@@ -1 +1,56 @@
-# Cte
+# CTE
+
+## Common Table Expressions (CTE)
+
+Common Table Expressions (CTE), also known as WITH queries, provide a way to define temporary result sets, that you can reference within a SELECT, INSERT, UPDATE, or DELETE statement. CTEs are quite useful when working with hierarchical or recursive queries, and they greatly improve the readability and maintainability of complex queries.
+
+### Basic Syntax
+
+A CTE is defined using the `WITH` keyword, followed by the CTE name, an optional column list, and the query that defines the CTE. The CTE is then referenced in the main query.
+
+Here's a basic example:
+
+```
+WITH my_cte (column1, column2)
+AS (
+    SELECT column1, column2
+    FROM my_table
+    WHERE condition
+)
+SELECT *
+FROM my_cte;
+```
+
+### Recursive CTEs
+
+One of the most powerful features of CTEs is their ability to work with recursive queries. A recursive CTE consists of two parts - an initial "anchor" query and a "recursive" query that refers back to the CTE.
+
+For example, assume we have a table `employees` with columns `id`, `name`, and `manager_id`, and we want to find the hierarchy of employees and their managers:
+
+```
+WITH RECURSIVE hierarchy (id, name, manager_id, level)
+AS (
+    -- Anchor query
+    SELECT id, name, manager_id, 1
+    FROM employees
+    WHERE manager_id IS NULL
+  UNION ALL
+    -- Recursive query
+    SELECT e.id, e.name, e.manager_id, h.level + 1
+    FROM employees e
+    JOIN hierarchy h ON e.manager_id = h.id
+)
+SELECT *
+FROM hierarchy
+ORDER BY level, manager_id;
+```
+
+This query starts with the root employees with no manager (level 1), and then recursively adds employees that report to the previously found employees, incrementing the `level` for each iteration.
+
+### Benefits of CTE
+
+1. **Readability and maintainability**: CTEs allow you to break down complex queries into smaller, more manageable parts.
+2. **Reusable subqueries**: CTEs can be referenced multiple times within the main query, which helps to avoid duplicating complex subqueries.
+3. **Recursive queries**: As demonstrated above, CTEs provide a neat way of working with recursive datasets and hierarchical structures.
+
+In conclusion, Common Table Expressions (CTE) are a valuable tool for PostgreSQL DBAs, providing improved query readability, maintainability, and support for advanced use-cases such as recursive queries.

src/data/roadmaps/postgresql-dba/content/104-learn-sql-concepts/103-advanced-topics/102-subqueries.md

@@ -1 +1,53 @@
-# Subqueries
+# Subqueries
+
+## Subqueries
+
+A subquery is a query that is embedded within another query, often to retrieve intermediate results for further processing by the outer query. Subqueries are an essential part of more complex SQL operations and allow you to perform multiple levels of data manipulation within a single query. 
+
+Subqueries can be used in various parts of an SQL statement, like the SELECT, FROM, WHERE, and HAVING clauses. They can also be classified based on their output or the relationship they represent, such as scalar subqueries, multi-value subqueries, or correlated subqueries. 
+
+### Scalar Subqueries
+Scalar subqueries return a single value (one row and one column) that can be directly used in the parent query. They are commonly used in SELECT or WHERE clauses to filter or calculate results based on some criteria.
+
+```sql
+SELECT product_id, product_name, price
+FROM products
+WHERE price > (
+    SELECT AVG(price)
+    FROM products
+);
+```
+
+In the above example, the scalar subquery returns the average price of all products, and the outer query returns those products whose price is greater than the average price.
+
+### Multi-Value Subqueries (IN Subqueries)
+Multi-value subqueries return a set of values (one column, multiple rows), typically used with the IN operator in the outer query to filter records. These subqueries help when you need to filter data based on a list of values generated by another query.
+
+```sql
+SELECT order_id, customer_id
+FROM orders
+WHERE customer_id IN (
+    SELECT customer_id
+    FROM customers
+    WHERE country = 'USA'
+);
+```
+
+In this example, the subquery returns a list of customer IDs from the USA, and the outer query fetches orders placed by these customers.
+
+### Correlated Subqueries
+Correlated subqueries are a special type of subquery in which the subquery references one or more columns from the outer query. This type of subquery is executed once for each row in the outer query, creating a dependent relationship between the two.
+
+```sql
+SELECT c.customer_id, c.customer_name
+FROM customers c
+WHERE 3 = (
+    SELECT COUNT(*)
+    FROM orders o
+    WHERE o.customer_id = c.customer_id
+);
+```
+
+In this example, the correlated subquery counts orders for each customer, and the outer query returns customers with exactly 3 orders.
+
+Understanding the use of subqueries and the different types can significantly enhance your ability to express powerful queries in PostgreSQL. Remember that subqueries may affect the performance of your query, so always consider performance optimization techniques and analyze the execution plan when working with complex subqueries.

src/data/roadmaps/postgresql-dba/content/104-learn-sql-concepts/103-advanced-topics/103-lateral-join.md

@@ -1 +1,45 @@
-# Lateral join
+# Lateral Join
+
+# Lateral Join
+
+A lateral join in PostgreSQL is an advanced querying feature that allows you to generate a set of rows based on the output of another subquery or function. It can be extremely useful in cases where you need to access elements of a row along with the output of a subquery that depends on the same row. Essentially, the LATERAL keyword allows a subquery in the FROM clause to refer to columns of preceding tables in the same FROM clause.
+
+## How Does It Work
+
+A lateral join works by applying a subquery for each of the rows in the main query, taking into account the current row elements. This allows you to compute a result set having a complex relationship between the main query rows and the lateral subquery's results.
+
+To use the LATERAL keyword, you simply include it in your query's FROM clause, followed by the subquery or function you want to join laterally.
+
+```sql
+SELECT ...
+FROM main_table, LATERAL (SELECT ... FROM ...)
+```
+
+Let's look at an example to better understand lateral joins.
+
+## Example
+
+Suppose you have two tables: `products (id, name, inventory)` and `sales (id, product_id, date, quantity)`.
+
+You want to display the information about each product and its most recent sale. This is how you would write the query using a lateral join:
+
+```sql
+SELECT p.id, p.name, p.inventory, s.date, s.quantity
+FROM products p, LATERAL (
+    SELECT date, quantity
+    FROM sales
+    WHERE product_id = p.id
+    ORDER BY date DESC
+    LIMIT 1
+) s;
+```
+
+In this example, the lateral subquery retrieves the most recent sale for the current product_id from the outer query. As a result, you'll get a list of products with their most recent sale information.
+
+## Benefits of Lateral Joins
+
+- They enable better code organization and more advanced query capabilities by allowing you to connect subqueries that have complex relationships with the main query.
+- They often lead to improved performance by reducing the need for nested loops or other inefficient query patterns.
+- They offer the ability to use functions or other advanced features, like aggregates or window functions, in a more flexible way within complex queries.
+
+In conclusion, lateral joins offer greater flexibility and improved performance for complex queries that involve processing information based on the output from other queries or functions.

src/data/roadmaps/postgresql-dba/content/104-learn-sql-concepts/103-advanced-topics/104-grouping.md

@@ -1 +1,97 @@
-# Grouping
+# Grouping
+
+## Grouping in PostgreSQL
+
+In this section, we will discuss the concept of grouping in PostgreSQL and how it can be utilized for data aggregation and analysis.
+
+### Overview
+
+Grouping is a powerful feature in SQL that allows you to aggregate and analyze data by grouping rows in a table based on specific columns. Using the `GROUP BY` clause, you can perform various aggregate functions such as sum, count, average, minimum, or maximum for each group of rows.
+
+### Syntax
+
+The basic syntax for using `GROUP BY` clause is as follows:
+
+```sql
+SELECT column1, column2, ... , aggregate_function(column)
+FROM table_name
+WHERE conditions
+GROUP BY column1, column2, ...;
+```
+
+The `GROUP BY` clause appears after the `WHERE` clause and before the optional `HAVING` clause, which filters the results of the grouping.
+
+### Examples
+
+Let's take a look at some examples using the `GROUP BY` clause.
+
+1. Count the number of employees in each department:
+
+```sql
+SELECT department, COUNT(*)
+FROM employees
+GROUP BY department;
+```
+
+2. Calculate the average salary for each job title:
+
+```sql
+SELECT job_title, AVG(salary)
+FROM employees
+GROUP BY job_title;
+```
+
+3. Find the total revenue for each product category:
+
+```sql
+SELECT category, SUM(revenue)
+FROM sales
+GROUP BY category;
+```
+
+### GROUP BY with HAVING
+
+In some cases, you might want to filter the groups based on certain conditions. For this, you can use the `HAVING` clause. It is similar to the `WHERE` clause, but it filters the aggregated results rather than the individual rows.
+
+Here's an example:
+
+```sql
+SELECT department, COUNT(*)
+FROM employees
+GROUP BY department
+HAVING COUNT(*) > 10;
+```
+
+This query will display departments with more than 10 employees.
+
+### Grouping Sets, Rollup, and Cube
+
+PostgreSQL provides additional functions for more advanced grouping operations:
+
+1. **Grouping Sets**: Generates multiple grouping sets within a single query.
+
+```sql
+SELECT department, job_title, COUNT(*)
+FROM employees
+GROUP BY GROUPING SETS ((department, job_title), (department), ());
+```
+
+2. **Rollup**: Generates multiple levels of aggregation from the most detailed to the total level.
+
+```sql
+SELECT department, job_title, COUNT(*)
+FROM employees
+GROUP BY ROLLUP (department, job_title);
+```
+
+3. **Cube**: Generates all possible combinations of grouped columns for more complex analysis.
+
+```sql
+SELECT department, job_title, COUNT(*)
+FROM employees
+GROUP BY CUBE (department, job_title);
+```
+
+### Conclusion
+
+In this section, we have introduced the concept of grouping in PostgreSQL, which allows you to perform powerful data analysis and aggregation using the `GROUP BY` clause. We have also covered advanced grouping operations such as grouping sets, rollup, and cube. With these tools in your arsenal, you'll be able to efficiently analyze and extract meaningful insights from your data.

src/data/roadmaps/postgresql-dba/content/104-learn-sql-concepts/103-advanced-topics/105-set-operations.md

@@ -1 +1,80 @@
-# Set operations
+# Set Operations
+
+## Set Operations in PostgreSQL
+
+In this section, we will discuss set operations in PostgreSQL. In relational algebra, set operations are the foundation of many advanced queries. PostgreSQL supports several set operations, including UNION, INTERSECT, and EXCEPT, that can be used to combine, compare and analyze data from multiple tables or subqueries.
+
+### UNION
+
+`UNION` combines the result sets of two or more `SELECT` statements into a single result set. It removes duplicate rows by default. If you want to preserve duplicates, you can use `UNION ALL`.
+
+```sql
+SELECT column1, column2, ...
+FROM table1
+UNION [ALL]
+SELECT column1, column2, ...
+FROM table2;
+```
+
+#### Example:
+
+```sql
+SELECT product_name, price
+FROM laptops
+UNION
+SELECT product_name, price
+FROM tablets;
+```
+
+### INTERSECT
+
+`INTERSECT` returns the common rows between the result sets of two `SELECT` statements. Similar to `UNION`, it removes duplicate rows unless `ALL` is specified. 
+
+```sql
+SELECT column1, column2, ...
+FROM table1
+INTERSECT [ALL]
+SELECT column1, column2, ...
+FROM table2;
+```
+
+#### Example:
+
+```sql
+SELECT product_name, price
+FROM laptop_sales
+INTERSECT
+SELECT product_name, price
+FROM tablet_sales;
+```
+
+### EXCEPT
+
+`EXCEPT` returns the rows from the first `SELECT` statement that do not appear in the result set of the second `SELECT` statement. It also removes duplicate rows, unless `ALL` is specified.
+
+```sql
+SELECT column1, column2, ...
+FROM table1
+EXCEPT [ALL]
+SELECT column1, column2, ...
+FROM table2;
+```
+
+#### Example:
+
+```sql
+SELECT product_name, price
+FROM laptop_sales
+EXCEPT
+SELECT product_name, price
+FROM tablet_sales;
+```
+
+### Rules and Considerations
+
+- The number and order of columns in both `SELECT` statements must be the same.
+- Data types of each corresponding column between the two `SELECT` statements must be compatible.
+- The names of the columns in the result set will be determined by the first `SELECT` query.
+- The result set will be sorted only if an `ORDER BY` clause is added to the end of the final `SELECT` query.
+
+To summarize, set operations enable us to combine, compare, and analyze data from multiple sources in PostgreSQL. They are powerful tools for data manipulation and can significantly improve the efficiency of your queries when used effectively.

src/data/roadmaps/postgresql-dba/content/104-learn-sql-concepts/103-advanced-topics/index.md

@@ -1 +1,63 @@
-# Advanced topics
+# Advanced Topics
+
+# Advanced SQL Topics
+
+After learning the basics of SQL concepts, it's time to dig deeper into some advanced topics. These topics will expand your knowledge and skills as a PostgreSQL DBA, enabling you to perform complex tasks, optimize database performance, and strengthen database security.
+
+## 1. Indexes
+
+Indexes are critical for optimizing database performance. They help databases find requested data quickly and efficiently. In this section, we will discuss:
+
+- Types of Indexes
+- Index creation and management
+- Index tuning and maintenance
+
+## 2. Views, Stored Procedures, and Triggers
+
+Views, stored procedures, and triggers are important elements in managing a PostgreSQL database. In this section, we will cover:
+
+- What are Views, and how to create and manage them
+- Understanding Stored Procedures, their creation and usage
+- Introduction to Triggers, and how to set them up
+
+## 3. Transaction Management
+
+Transactions are a vital aspect of data consistency and integrity. In this section, we will explore:
+
+- Introduction to Transactions
+- ACID properties of transactions
+- Transaction Isolation Levels in PostgreSQL
+
+## 4. Performance Tuning
+
+Optimizing database performance is a crucial skill for a PostgreSQL DBA. This section will focus on:
+
+- Query optimization techniques
+- Analyzing and tuning database performance
+- Tools and utilities for monitoring and troubleshooting
+
+## 5. Security and User Management
+
+Understanding security and user management is essential to protecting your data. In this section, we will discuss:
+
+- PostgreSQL Authentication Mechanisms
+- Role-Based Access Control
+- Encryption, and Data Security Best Practices
+
+## 6. Backup and Recovery
+
+Adequate backup and recovery strategies are necessary for ensuring data durability and disaster recovery. In this section, we will explore:
+
+- Types of backups in PostgreSQL
+- Backup strategies and best practices
+- Disaster recovery techniques and tools
+
+## 7. Replication and High Availability
+
+For many businesses and applications, database high availability is a critical requirement. In this section, you will learn:
+
+- Introduction to replication in PostgreSQL
+- Types of replication (logical, streaming)
+- Tools and approaches for high availability
+
+By studying these advanced SQL topics, you will become a more knowledgeable and proficient PostgreSQL DBA. Understanding these areas will help you effectively manage, optimize, and secure your PostgreSQL databases, and provide you with a strong foundation for tackling real-world challenges in database administration.

src/data/roadmaps/postgresql-dba/content/104-learn-sql-concepts/index.md

@@ -1 +1,57 @@
-# Learn sql concepts
+# Learn SQL Concepts
+
+# Learn SQL Concepts
+
+In this chapter, we will discuss essential SQL concepts that every PostgreSQL Database Administrator (DBA) should be familiar with. Understanding these concepts is crucial for effectively managing, querying, and maintaining your databases.
+
+## SQL (Structured Query Language)
+
+SQL is a domain-specific language designed for managing data held in relational database management systems (RDBMS) such as PostgreSQL. It allows you to create, read, update, and delete records in your databases, as well as define and manage the schema and data access patterns.
+
+## Tables
+
+Tables are the fundamental components of a relational database. They consist of rows and columns, with each row representing an individual record and columns representing the attributes (fields) of those records.
+
+- **Table Schema**: The structure and constraints of a table, including column names, data types, and any constraints or indexes.
+
+- **Primary Key**: A unique identifier for each row in a table, generally comprising one or more columns. A primary key ensures that no two records can have the same identifier and guarantees referential integrity for related tables.
+
+- **Foreign Key**: A column (or set of columns) that refers to the primary key of another table, establishing relationships between the two tables and aiding in data consistency and integrity.
+
+## Queries
+
+Queries in SQL are used to extract and manipulate data stored in databases. The most common operations include:
+
+- **SELECT**: Retrieve data from one or more tables or views according to specified criteria.
+
+- **INSERT**: Add a new record or records to a table.
+
+- **UPDATE**: Modify existing records in a table based on specified criteria.
+
+- **DELETE**: Remove records from a table based on specified criteria.
+
+## Joins
+
+Joins are a way of combining rows from two or more tables by matching columns between them. This is done to assemble data from different tables into a single result set.
+
+- **Inner Join**: Returns rows from both tables that have matching column values.
+
+- **Left Join**: Returns all rows from the left table and any matching rows from the right table, filling in missing values with NULL.
+
+- **Right Join**: Returns all rows from the right table and any matching rows from the left table, filling in missing values with NULL.
+
+- **Full Outer Join**: Returns all rows from both tables when there is a match, and fills in missing values with NULL when no match is found.
+
+## Transactions
+
+Transactions are a sequence of operations that follow the ACID (Atomicity, Consistency, Isolation, and Durability) properties, ensuring that your database remains in a consistent state even when multiple users are concurrently executing queries.
+
+- **Atomicity**: Either all operations in a transaction are executed or none are.
+
+- **Consistency**: After a transaction has been completed, the database will remain in a consistent state.
+
+- **Isolation**: Each transaction is isolated from others, so their execution does not affect other transactions' results.
+
+- **Durability**: Once a transaction is committed, its changes persist in the database, even in the event of system failures.
+
+By understanding these core SQL concepts, you will be better equipped to manage and maintain your PostgreSQL databases effectively. In the following chapters, we will delve deeper into each concept and discuss best practices and tips for optimizing your database's performance.

src/data/roadmaps/postgresql-dba/content/105-configuring-postgresql/100-resources-usage.md

@@ -1 +1,68 @@
-# Resources usage
+# Resources Usage
+
+# Resource Usage in PostgreSQL
+
+Resource usage refers to the management of various resources such as memory, CPU, and disk usage while utilizing PostgreSQL. Effective management of these resources is crucial for achieving optimal performance and ensuring smooth operation of the database. In this section, we will discuss the key configuration parameters related to resource usage in PostgreSQL.
+
+## Memory Usage
+
+PostgreSQL utilizes memory for several purposes such as caching, sorting, and connection handling. To manage memory usage efficiently, we need to focus on the following parameters:
+
+### `shared_buffers`
+
+This configuration parameter determines the amount of memory reserved for shared memory buffers. It is used by all PostgreSQL processes for various purposes, such as caching frequently accessed data. A recommended value is around 25% of the total system memory.
+
+```ini
+shared_buffers = 4GB
+```
+
+### `work_mem`
+
+`work_mem` sets the amount of memory used per query operation, such as sorting and hashing. Increasing this value allows more memory-intensive tasks to execute efficiently but may consume a lot of memory when executing multiple tasks concurrently. The appropriate value depends on the workload and available memory.
+
+```ini
+work_mem = 64MB
+```
+
+### `maintenance_work_mem`
+
+This parameter sets the amount of memory used for maintenance tasks like VACUUM, CREATE INDEX, and ALTER TABLE. A higher value speeds up these operations but may consume more memory. 
+
+```ini
+maintenance_work_mem = 256MB
+```
+
+## CPU Usage
+
+PostgreSQL uses the CPU for executing queries and performing maintenance tasks. The key configuration parameter related to CPU usage is:
+
+### `max_parallel_workers`
+
+This parameter determines the maximum number of parallel workers that can be active concurrently. Parallel query execution can significantly speed up the processing time for large and complex queries by utilizing multiple CPU cores.
+
+```ini
+max_parallel_workers = 4
+```
+
+## Disk Usage
+
+PostgreSQL stores data and indexes on the disk. Efficient management of the disk space significantly affects the database's performance. The important parameters related to disk usage include:
+
+### `default_statistics_target`
+
+This parameter sets the default sample size for statistics collection by the ANALYZE command. A higher value can lead to more accurate query plans, but at the cost of increased disk space usage.
+
+```ini
+default_statistics_target = 50
+```
+
+### `checkpoint_timeout` and `max_wal_size`
+
+The Write Ahead Log (WAL) records changes to the database and is used for recovery in case of a crash. `checkpoint_timeout` sets the frequency of checkpoints, while `max_wal_size` controls the maximum size of the WAL files.
+
+```ini
+checkpoint_timeout = 5min
+max_wal_size = 2GB
+```
+
+These are just a few of the critical parameters you can configure to optimize the resource usage in PostgreSQL. Keep in mind that every workload is unique, and it is important to monitor and understand your database's performance to adjust the settings accordingly.

src/data/roadmaps/postgresql-dba/content/105-configuring-postgresql/101-write-ahead-log.md

@@ -1 +1,38 @@
-# Write ahead log
+# Write-ahead Log
+
+
+# Write Ahead Log (WAL)
+
+The Write Ahead Log (WAL) is an essential component of PostgreSQL's architecture. It ensures data consistency and durability by recording all the changes made to the database before they are actually applied to the data files. When a transaction is committed, its data is written to the WAL, and only after that, it is applied to the database.
+
+## How WAL works
+
+The basic flow of data through a PostgreSQL system with WAL includes:
+
+1. Changes made to the database are first recorded in the WAL.
+2. WAL data is flushed to disk periodically or when a transaction commits.
+3. Checkpoints occur at intervals, ensuring all changes are applied to the database files.
+4. In case of a crash, the WAL is used to recover the uncommitted transactions.
+
+This process guarantees that even if the database crashes, all the committed transactions can be recovered by reapplying the WAL entries.
+
+## Benefits of WAL
+
+- **Data integrity:** WAL ensures that the data remains consistent across crashes or failures, as it logs all the changes before they are written to the data files.
+- **Crash recovery:** In case of a crash, the WAL can be used to recover the committed transactions by replaying them.
+- **Performance improvements:** Periodic flushing of WAL data reduces the number of random I/O operations and improves write performance.
+- **Support for replication and backup:** WAL can be archived and used for Point-In-Time Recovery (PITR). Additionally, it enables streaming replication and other advanced techniques to ensure high availability.
+
+## Configuring WAL
+
+You can configure WAL by adjusting the `postgresql.conf` file or by modifying the startup command options. Here are some important configuration settings related to WAL:
+
+- `wal_level`: Determines the amount of information written to the WAL. Set it to 'minimal', 'replica', or 'logical'.
+- `fsync`: Determines if the PostgreSQL server should request the operating system to flush the WAL data to disk. Set it to 'on' (recommended) for the majority of situations or 'off' to improve performance at the cost of data integrity.
+- `synchronous_commit`: Specifies whether transaction commits should wait for WAL records to be flushed to disk. Set it to 'on' (default) for full transaction durability or 'off' for improved write performance at the risk of losing recent transactions.
+
+In addition to these settings, there are several other options related to WAL archiving, checkpoint settings, and replication. For a complete list, refer to the [official documentation](https://www.postgresql.org/docs/current/runtime-config-wal.html).
+
+--- 
+
+In conclusion, Write Ahead Log (WAL) is a vital part of PostgreSQL's architecture that ensures data consistency, durability, and overall performance. Understanding and configuring WAL settings can help you tailor your PostgreSQL database to match your specific requirements and performance goals.

src/data/roadmaps/postgresql-dba/content/105-configuring-postgresql/102-vacuums.md

@@ -1 +1,37 @@
-# Vacuums
+# Vacuums
+
+## Vacuuming in PostgreSQL
+
+Vacuuming is an essential housekeeping process in PostgreSQL that helps maintain the overall health and performance of the database. By design, PostgreSQL is a Multi-Version Concurrency Control (MVCC) system, which means that each transaction works with a snapshot of the database at a certain point in time. As a result, when a row is updated or deleted, a new version of the row is created, while the old version remains. This increases the size of the database and can lead to performance issues over time. Vacuuming reclaims storage occupied by dead rows and optimizes the performance of queries and the database as a whole.
+
+In this section, we will discuss different types of vacuuming processes and how to configure them effectively in PostgreSQL.
+
+### Types of Vacuuming Processes
+
+There are three main types of vacuuming processes in PostgreSQL:
+
+1. **Standard Vacuum:** This process reclaims storage space and optimizes the database by removing dead rows and updating internal statistics. It does not require any additional parameters and is invoked by the `VACUUM` command.
+
+2. **Full Vacuum:** This is a more aggressive and time-consuming version of the standard vacuum. It reclaims more storage space by compacting the table, but it may also lock the table during the process. This can be invoked by the `VACUUM FULL` command.
+
+3. **Analyze:** This process updates internal statistics about the distribution of rows and the size of the tables to optimize query planning. It does not free any storage space. This can be invoked by the `ANALYZE` command.
+
+### Configuring Vacuuming in PostgreSQL
+
+PostgreSQL has an automatic background process called the "autovacuum" that takes care of standard vacuuming and analyzing operations. By default, the autovacuum is enabled, and it's recommended to keep it that way. However, it's essential to fine-tune its configuration for optimal performance. Here are some key configuration parameters related to vacuuming:
+
+- `autovacuum_vacuum_scale_factor`: This parameter determines the fraction of the table size that must no longer be useful (dead rows) before the table is vacuumed. The default value is `0.2`, meaning 20% of the table must be dead rows before the table is vacuumed.
+
+- `autovacuum_analyze_scale_factor`: This parameter determines the fraction of the table size that must change (inserts, updates, or deletes) before the table is analyzed. The default value is `0.1`, meaning at least 10% of the table must have changed before the table is analyzed.
+
+- `maintenance_work_mem`: This parameter determines the amount of memory available for maintenance tasks like vacuuming. Increasing this value can speed up the vacuuming process. The default value is `64 MB`.
+
+- `vacuum_cost_limit`: This parameter is used by the cost-based vacuum delay feature, which can slow down the vacuuming process to reduce the impact on the overall performance of the system. The default value is `200`.
+
+Remember that these parameter values should be adjusted based on your system's hardware, workload, and specific requirements.
+
+### Monitoring Vacuum Activity
+
+You can monitor the vacuuming activities in your PostgreSQL database through the `pg_stat_user_tables` and `pg_stat_bgwriter` views. These views provide insights into the number of vacuum and analyze operations performed on each table and the overall effectiveness of the vacuuming process.
+
+In conclusion, vacuuming is a critical aspect of PostgreSQL administration that helps to clean up dead rows, update internal statistics, and optimize the database engine for better performance. As a PostgreSQL DBA, it's essential to understand the various types of vacuums, configure them appropriately, and monitor their activities. With proper vacuuming settings, you can achieve a more efficient and high-performing PostgreSQL database.

src/data/roadmaps/postgresql-dba/content/105-configuring-postgresql/103-replication.md

@@ -1 +1,30 @@
-# Replication
+# Replication
+
+## Replication in PostgreSQL
+
+Replication in PostgreSQL is a technique used for creating and maintaining one or more copies of the database, called replicas, across different servers so as to assure high-availability and fault-tolerance. PostgreSQL supports both physical and logical replication, which differ in terms of what data gets replicated and how it is used in the target databases. Let's dive deeper into each type.
+
+### Physical Replication
+
+Physical replication involves copying the exact data files and file system layout of a primary database to one or more secondary databases called standbys. With this method, all changes to the primary database are transferred to the standby in the form of write-ahead log (WAL) records. This ensures that the primary and standby databases are always identical.
+
+Physical replication can be either synchronous or asynchronous:
+
+- **Synchronous Replication**: With synchronous replication, the primary database waits for changes to be written to the standby before considering a transaction complete. This guarantees data consistency between primary and standby databases but can have an impact on performance.
+- **Asynchronous Replication**: In asynchronous replication, the primary database does not wait for changes to be written to the standby before considering a transaction complete. This provides better performance but risks data loss due to the possibility of the primary node failing before changes are written to the standby.
+
+To set up physical replication, you need to configure both primary (`postgresql.conf` and `pg_hba.conf`) and standby (`recovery.conf` and `postgresql.conf`) nodes accordingly.
+
+### Logical Replication
+
+Logical replication is a more flexible way of replicating data in PostgreSQL where you can have only specific tables or databases replicated, and even apply database-level transformations during replication. With logical replication, the primary database sends changes in the form of logical events, not WAL records. Logical replication is asynchronous and uses logical decoding and replication slots to ensure data consistency.
+
+Since logical replication is table-level, you can have writeable replicas, which may serve specific purposes such as analytics or reporting. Additionally, logical replication supports cross-version replication, making major version upgrades simpler.
+
+To set up logical replication, create a Publication on the primary node, and a Subscription on the replica for each table you want to replicate.
+
+### Choosing Between Physical and Logical Replication
+
+The choice between physical and logical replication depends on the specific requirements of your application. If you need a complete copy of your database with the sole purpose of providing a high-availability failover, physical replication is the best choice. On the other hand, if you need only a subset of your data, require writeable replicas, or need to support cross-version replication, then logical replication is the way to go.
+
+In summary, replication in PostgreSQL is a powerful feature that helps assure high-availability and fault-tolerance. Understanding the differences between physical and logical replication will help you choose the best solution to meet your requirements.

src/data/roadmaps/postgresql-dba/content/105-configuring-postgresql/104-query-planner.md

@@ -1 +1,35 @@
-# Query planner
+# Query Planner
+
+## Query Planner
+
+The query planner (also known as query optimizer) is a critical component in the PostgreSQL database system that analyzes, optimizes, and plans the execution of SQL queries. Its main goal is to find the most efficient execution plan for a given query, taking into consideration several factors, such as the structure of the tables, the available indexes, and the contents of the query itself. This allows PostgreSQL to provide a fast and efficient response to your data retrieval or manipulation requests.
+
+### Key Concepts
+
+1. **Execution plans**: The query planner generates several possible execution plans for a given query. Each plan represents a different approach and sequence of steps needed to retrieve or modify the required data. The query planner chooses the plan with the lowest cost, which is expected to execute the query in the least amount of time.
+
+2. **Estimation and statistics**: The query planner relies on statistical information about the distribution of data in the tables, such as the number of rows, the average size of rows, and the uniqueness of values in columns. This information is collected by the "ANALYZE" command, which is run automatically when the "autovacuum" feature is enabled or can be manually executed by the DBA. Accurate and up-to-date statistics are crucial for the query planner to make informed decisions about the best execution plan.
+
+3. **Cost model**: The query planner assigns a cost to each possible execution plan, based on factors such as the expected number of disk page accesses, CPU usage, and the complexity of the operations involved. The cost model aims to express the total resource usage of a plan, making it possible to compare different plans and choose the one with the lowest cost.
+
+### Configuration
+
+PostgreSQL offers several configuration options that can be used to influence the behavior of the query planner:
+
+- `default_statistics_target`: This parameter controls the number of samples taken by "ANALYZE" to calculate statistics for the query planner. Higher values increase the accuracy of the statistics at the cost of longer ANALYZE times.
+
+- `enable_seqscan`, `enable_indexscan`, `enable_bitmapscan`, `enable_indexonlyscan`, `enable_sort`, and `enable_material`: These parameters can be used to enable or disable specific types of query execution plans. This can be useful for tuning the query planner's behavior for particular workloads. However, be cautious when changing these settings, as disabling a plan type may lead to slower query execution.
+
+- `random_page_cost` and `seq_page_cost`: These parameters help the query planner estimate the cost of disk page accesses. `random_page_cost` is the cost of a non-sequentially fetched disk page, and `seq_page_cost` is the cost of a sequentially fetched disk page. Adjusting these values may be necessary on systems with unusual hardware configurations or performance characteristics.
+
+Remember that any changes made to the configuration should be thoroughly tested before applying them in a production environment, to ensure that the desired improvements in query performance are achieved.
+
+### Monitoring and Troubleshooting
+
+Understanding the query planner and how it generates execution plans can be essential for diagnosing performance issues in a PostgreSQL database:
+
+- `EXPLAIN`: Use the `EXPLAIN` command to inspect the execution plan generated by the query planner for a specific query. This can help you identify potential inefficiencies or areas for optimization, such as missing indexes or unnecessary table scans. 
+
+- `auto_explain`: The `auto_explain` module is an optional extension that can be loaded by adding it to `shared_preload_libraries`. It automatically logs execution plans for slow queries, making it easier to identify and troubleshoot performance issues.
+
+In conclusion, the query planner is a vital part of the PostgreSQL system that aims to ensure efficient query execution. Understanding its basic concepts, configuring it to suit your particular workload, and monitoring its operations are key aspects of achieving optimal database performance.

src/data/roadmaps/postgresql-dba/content/105-configuring-postgresql/105-checkpoints-background-writer.md

@@ -1 +1,24 @@
-# Checkpoints background writer
+# Checkpoints
+
+## Checkpoints and Background Writer
+
+In PostgreSQL, data is written into the Write-Ahead Log (WAL) first, before being written to the actual data files. Checkpoints are points in the WAL where all the changes since the last checkpoint have been written to the data files. The process that flushes the changes from WAL to the data files is known as the *background writer*.
+
+### Checkpoints
+
+Checkpoints ensure data durability by flushing modified database buffers to the disk. By periodically performing checkpoints, PostgreSQL reduces the amount of time required for crash recovery. Checkpoints are initiated under the following conditions:
+
+1. A configurable time duration has passed since the last checkpoint (controlled by the `checkpoint_timeout` parameter).
+2. The number of WAL segments exceeded the `max_wal_size` parameter.
+
+It's crucial to strike a balance when configuring checkpoints. Infrequent checkpoints can result in longer recovery times, whereas frequent checkpoints can lead to increased I/O overhead and reduced performance.
+
+### Background Writer
+
+The **background writer** is a PostgreSQL background process that continuously flushes dirty (modified) data buffers to free up memory for more caching. The primary goal of the background writer is to minimize the need for future checkpoints, thus reducing the I/O spike during those events. The following parameters control the behavior of the background writer:
+
+- `bgwriter_lru_multiplier`: Controls the speed at which the background writer scans the buffer. A higher value will cause it to scan more aggressively.
+- `bgwriter_lru_maxpages`: Determines the maximum number of dirty buffers that the background writer can clean in one round.
+- `bgwriter_flush_after`: Configures the number of pages the background writer flushes after a pause. By introducing delays during flushing, the background writer can reduce "bursty" I/O activity.
+
+It is important to understand the behavior and tuning of both checkpoints and the background writer when configuring PostgreSQL, as their efficient operation has a direct impact on the database's performance, I/O, and recovery times. Keep a close eye on your system's checkpoint and background writer activity so you can make appropriate adjustments according to your specific use case and performance requirements.

src/data/roadmaps/postgresql-dba/content/105-configuring-postgresql/106-adding-extensions.md

@@ -1 +1,64 @@
-# Adding extensions
+# Adding Extra Extensions
+
+## Adding Extensions
+
+In PostgreSQL, extensions are packages that contain SQL objects such as functions, operators, and data types. These extensions serve to extend the capabilities of PostgreSQL and ease the development of applications. Some common extensions include PostGIS (for spatial data support), pgcrypto (for encryption support), and hstore (for key-value store support).
+
+### Steps to Add an Extension
+
+1. **Install the Extension Package:** Before adding the extension to your PostgreSQL database, make sure the extension package is installed on your system. You can usually find these packages in your operating system's package manager.
+
+```sh
+# Example for Debian/Ubuntu-based systems
+sudo apt-get install postgresql-contrib
+```
+
+2. **Add the Extension to a Database:** Once the package is installed, connect to the database where you want to add the extension:
+
+```sh
+psql -U <username> -d <database_name>
+```
+
+Then, use the `CREATE EXTENSION` command to add the extension you want:
+
+```sql
+CREATE EXTENSION IF NOT EXISTS <extension_name>;
+```
+
+For example, to add the `hstore` extension:
+
+```sql
+CREATE EXTENSION IF NOT EXISTS hstore;
+```
+
+3. **Verify the Extension:** After adding the extension to your database, you can verify that it's been installed correctly by running the `SELECT` statement with `pg_available_extensions`:
+
+```sql
+SELECT * FROM pg_available_extensions WHERE name = '<extension_name>';
+```
+
+You should see the installed extension in the result.
+
+4. **Grant Usage Permissions:** Depending on your use case or the environment, you might need to grant usage permissions to specific users or roles:
+
+```sql
+GRANT USAGE ON SCHEMA <schema_name> TO <user_or_role>;
+```
+
+### Updating an Extension
+
+Extensions usually evolve over time, and you might need to update them to a newer version. To update an extension, use the `ALTER EXTENSION` command:
+
+```sql
+ALTER EXTENSION <extension_name> UPDATE TO '<new_version>';
+```
+
+### Removing an Extension
+
+To remove an installed extension from your PostgreSQL database, use the `DROP EXTENSION` command:
+
+```sql
+DROP EXTENSION IF EXISTS <extension_name> [CASCADE];
+```
+
+_Adding extensions in PostgreSQL allows you to benefit from numerous additional functionalities, creating a more powerful and versatile database system. However, be cautious while installing extensions, as some of them might have security or stability implications._

src/data/roadmaps/postgresql-dba/content/105-configuring-postgresql/107-reporting-logging-statistics.md

@@ -1 +1,51 @@
-# Reporting logging statistics
+# Reporting Logging and Statistics
+
+## Reporting Logging Statistics
+
+In this section, we will discuss how to configure PostgreSQL to report and log various statistics. These statistics can be incredibly valuable for monitoring and optimization purposes, especially for database administrators (DBA) who are responsible for managing and maintaining the database system.
+
+### Why Log Statistics
+
+Logging statistics help DBAs to:
+
+1. Identify performance issues and potential bottlenecks.
+2. Monitor the overall health of the system.
+3. Plan for capacity or hardware upgrades.
+4. Debug and optimize queries.
+5. Ensure compliance with regulatory requirements, such as auditing.
+
+### Configuration Parameters
+
+PostgreSQL offers several configuration parameters that allow you to control the reporting and logging of statistics. These are typically set in the `postgresql.conf` file, and they can be modified even while the server is running using the `ALTER SYSTEM` command.
+
+Here are some key parameters to consider:
+
+- `log_statement_stats`: When enabled (set to 'on'), this parameter logs the performance statistics for each executed statement. Useful in debugging slow queries.
+
+- `log_parser_stats`, `log_planner_stats`, `log_executor_stats`: These parameters enable more detailed logging of various subsystems within the PostgreSQL engine.
+
+- `log_duration`: When enabled (set to 'on'), this parameter logs the duration of each executed statement. This information can be useful for identifying slow queries.
+
+- `log_min_duration_statement`: Specifies the minimum duration (in milliseconds) of a statement to be logged. Only statements with an execution time equal to or greater than this value will be logged. This is useful for filtering out less significant queries.
+
+- `log_checkpoints`: When enabled (set to 'on'), this parameter logs information about checkpoint events. These events are a part of PostgreSQL's write-ahead logging (WAL) mechanism and can affect performance in specific scenarios.
+
+- `log_connections` and `log_disconnections`: These parameters log any new connections and disconnections to/from the PostgreSQL server, which helps to monitor access patterns and detect possible security issues.
+
+### Example:
+
+Here's an example of how to configure the `postgresql.conf` file to log statement statistics and durations:
+
+```
+log_statement_stats = on
+log_duration = on
+log_min_duration_statement = 100
+```
+
+This configuration will log the statistics for all queries that take 100 milliseconds or more to execute, along with their duration.
+
+### Analyzing Logged Statistics
+
+Once the appropriate statistics are being logged, you can use various external tools to analyze these logs and gather insights. Some popular tools include [pgBadger](https://github.com/darold/pgbadger), [pg_stat_statements](https://www.postgresql.org/docs/current/pgstatstatements.html), and [pganalyze](https://pganalyze.com/).
+
+By regularly monitoring and analyzing your PostgreSQL logs, you'll be better equipped to manage your database system efficiently and effectively.

src/data/roadmaps/postgresql-dba/content/105-configuring-postgresql/index.md

@@ -1 +1,65 @@
-# Configuring postgresql
+# Configuring PostgreSQL
+
+# Configuring PostgreSQL
+
+As a PostgreSQL DBA, it is essential to understand how to configure your PostgreSQL database to achieve optimal performance, security, and maintainability. In this guide, we will discuss various aspects of configuring PostgreSQL while covering topics such as configuration files, memory settings, connection settings, and logging.
+
+## Configuration Files
+
+The primary configuration file for PostgreSQL is the `postgresql.conf` file, which is typically located in the _data_ directory. This file contains settings for various parameters that determine the runtime behavior of the database server. Another important file is `pg_hba.conf`, which is responsible for client authentication and defines access rules to databases and users.
+
+### postgresql.conf
+
+This file contains several settings that can be modified according to your database requirements. The settings are organized in categories, including:
+
+* File Locations
+* Connection Settings
+* Memory Settings
+* Query Tuning
+* Logging
+
+Let's take a closer look at some key parameters in each category:
+
+#### Connection Settings
+
+* `listen_addresses`: Specifies the IP addresses that the server should listen on. Use `*` to listen on all available interfaces, or specify a comma-separated list of IP addresses.
+* `port`: Determines the TCP port number PostgreSQL server listens on. The default is 5432.
+
+#### Memory Settings
+
+* `shared_buffers`: Sets the amount of memory used for shared buffers. Increasing this value may improve performance, depending on your system resources.
+* `effective_cache_size`: Tells the query planner the amount of memory available for caching data. It helps the query planner in choosing the most optimal query plan.
+
+#### Query Tuning
+
+* `work_mem`: Specifies the amount of memory available for sorting and hashing operations when executing complex queries.
+* `maintenance_work_mem`: Determines the amount of memory available for maintenance tasks like vacuuming and index creation.
+
+#### Logging
+
+* `log_destination`: Determines where to send server log output. Multiple destinations can be specified using a comma-separated list.
+* `logging_collector`: Logging collector will manage the process of rotating and archiving log files.
+
+### pg_hba.conf
+
+This file contains records that define authentication rules for connecting clients, based on their IP address and user or database. Each record has the following format:
+
+```
+<connection_type> <database> <user> <address> <authentication method>
+```
+
+For example, to allow all users to connect from any IP address using `md5`-encrypted passwords, you would add the following line:
+
+```
+host all all 0.0.0.0/0 md5
+```
+
+## Applying Configuration Changes
+
+To apply changes made in the `postgresql.conf` file, you generally need to restart the PostgreSQL server. However, some parameters can be applied without a restart by using the `pg_ctl` command or the `ALTER SYSTEM` SQL command.
+
+For changes in `pg_hba.conf`, you need to reload the server by using the `pg_ctl` command or sending the `SIGHUP` signal to the PostgreSQL process.
+
+## Conclusion
+
+Configuring PostgreSQL involves understanding and modifying various settings in the `postgresql.conf` and `pg_hba.conf` files. A well-configured database server will result in improved performance, better security, and easy maintainability. As a PostgreSQL DBA, it is crucial to get familiar with these configurations and continually fine-tune them as needed.

src/data/roadmaps/postgresql-dba/content/106-postgresql-security-concepts/100-object-priviliges/100-grant-revoke.md

@@ -1 +1,66 @@
-# Grant revoke
+# Grant / Revoke
+
+# Object Privileges: Grant and Revoke
+
+In this section, we are going to discuss the essential concepts of **GRANT** and **REVOKE** in PostgreSQL. These terms relate to granting or revoking privileges for specific database objects, allowing you to control access and maintain security within your database environment.
+
+## Granting Privileges
+
+The **GRANT** command allows you to grant specific privileges on a database object to a user or a group of users. PostgreSQL supports several object types, such as:
+
+- TABLE
+- SEQUENCE
+- DATABASE
+- SCHEMA
+- FUNCTION
+- FOREIGN DATA WRAPPER
+- FOREIGN SERVER
+- LANGUAGES
+- LARGE OBJECT
+
+The general syntax for the **GRANT** command is as follows:
+
+```sql
+GRANT privilege [, ...]
+ON object_type object_name [, ...]
+TO {user | GROUP group | PUBLIC} [, ...]
+[WITH ADMIN OPTION];
+```
+
+Here's an example to illustrate how to grant the SELECT privilege on a table called `employees` to a user named `john`:
+
+```sql
+GRANT SELECT ON TABLE employees TO john;
+```
+
+You can also grant multiple privileges at once:
+
+```sql
+GRANT SELECT, INSERT, UPDATE ON TABLE employees TO john;
+```
+
+## Revoking Privileges
+
+The **REVOKE** command is used to revoke privileges previously granted to a user or a group of users. The general syntax is similar to the **GRANT** command, but you use **REVOKE** instead:
+
+```sql
+REVOKE privilege [, ...]
+ON object_type object_name [, ...]
+FROM {user | GROUP group | PUBLIC} [, ...];
+```
+
+Here's an example illustrating how to revoke the SELECT privilege on the `employees` table from the user `john`:
+
+```sql
+REVOKE SELECT ON TABLE employees FROM john;
+```
+
+Like **GRANT**, you can revoke multiple privileges at once:
+
+```sql
+REVOKE SELECT, INSERT, UPDATE ON TABLE employees FROM john;
+```
+
+## Summary
+
+In this section, we discussed the importance of the **GRANT** and **REVOKE** commands in PostgreSQL. These commands allow a database administrator to grant or revoke specific privileges on database objects, ensuring secure access control within the database environment. Understanding and correctly implementing these privileges is a crucial aspect of the PostgreSQL DBA role.

src/data/roadmaps/postgresql-dba/content/106-postgresql-security-concepts/100-object-priviliges/101-default-priviliges.md

@@ -1 +1,47 @@
-# Default priviliges
+# Default Privileges
+
+## Default Privileges in PostgreSQL
+
+Default privileges in PostgreSQL are the permissions that are automatically assigned to objects within a database when they are created. These privileges determine what actions can be performed on the objects and by which users or roles.
+
+### Understanding Default Privileges
+
+By default, PostgreSQL assigns certain privileges to the user or role that creates the object, as well as the public group. Here's a breakdown of default privileges assigned to different object types:
+
+- **Tables**: The creator of a table gets all the privileges including SELECT, INSERT, UPDATE, DELETE, TRUNCATE, REFERENCES, and TRIGGER. The PUBLIC group doesn't have any privileges by default.
+
+- **Sequences**: The user who created the sequence gets USAGE, SELECT, UPDATE privileges. Similarly, the PUBLIC group doesn't have any privileges by default.
+
+- **Functions**: The creator of a function gets EXECUTE privilege, and the PUBLIC group gets no privileges by default.
+
+- **Types and Domains**: The user who creates the TYPE or DOMAIN gets USAGE privilege, and the PUBLIC group doesn't have any privileges by default.
+
+- **Schemas**: The creator of a schema gets CREATE, USAGE, and TEMPORARY privileges. The PUBLIC group gets only the USAGE privilege on the schema.
+
+### Modifying Default Privileges
+
+You can modify the default privileges for newly created objects by using the `ALTER DEFAULT PRIVILEGES` command. This command allows to specify roles or users, set the grant options, and specify the object we want to modify the default privileges for.
+
+#### Syntax
+
+```sql
+ALTER DEFAULT PRIVILEGES
+    [ FOR { ROLE | USER } target_role [, ...] ]
+    [ IN SCHEMA schema_name [, ...] ]
+    { GRANT | REVOKE [ GRANT OPTION FOR ] } privileges
+    ON { ALL TABLES | ALL SEQUENCES | ALL FUNCTIONS | ALL TYPES | ALL DOMAINS }
+    TO { [ GROUP ] role_name | PUBLIC } [, ...] [ WITH HIERARCHY ]
+```
+
+#### Example
+
+Here's an example of how to grant SELECT permission on all newly created tables to the role `readonly_user`:
+
+```sql
+ALTER DEFAULT PRIVILEGES
+    IN SCHEMA public
+    GRANT SELECT ON TABLES
+    TO readonly_user;
+```
+
+Keep in mind that modifying default privileges only applies to future objects, not existing ones. If you want to modify the privileges of existing objects, you have to use the `GRANT` and `REVOKE` commands for each object explicitly.

src/data/roadmaps/postgresql-dba/content/106-postgresql-security-concepts/100-object-priviliges/index.md

@@ -1 +1,59 @@
-# Object priviliges
+# Object Priviliges
+
+# PostgreSQL Object Privileges
+
+Object privileges are a set of permissions that provide a secure way to manage access control and regulate users' actions on specific database objects such as tables, sequences, functions, and more. This section will provide a brief summary of object privileges, the types of object privileges, and how to define them in PostgreSQL.
+
+## Types of Object Privileges
+
+PostgreSQL provides multiple types of object privileges, depending on the type of object. Some common object types and their corresponding privileges are:
+
+- **Tables**: SELECT, INSERT, UPDATE, DELETE, TRUNCATE, REFERENCES, and TRIGGER.
+- **Sequences**: USAGE, SELECT, UPDATE.
+- **Functions**: EXECUTE.
+- **Types**: USAGE.
+
+These privileges regulate which database operations a user can execute on a specific object.
+
+## Granting and Revoking Object Privileges
+
+To grant or revoke object privileges, use the `GRANT` and `REVOKE` commands, respectively. The basic syntax for granting privileges on a table is as follows:
+
+```
+GRANT privilege [, ...]
+ON object_type object_name [, ...]
+TO role_specification [, ...]
+[WITH CHECK OPTION | WITH OUT CHECK OPTION]
+[WITH CASCADE | WITH RESTRICT]
+[RESIDUAL]
+```
+
+For example, to grant SELECT, INSERT, and UPDATE privileges on the table "employees" to the user "HR_department", you can execute the following SQL command:
+
+```
+GRANT SELECT, INSERT, UPDATE
+ON TABLE employees
+TO HR_department;
+```
+
+To revoke any of these privileges, you can use the `REVOKE` command with the same syntax as the `GRANT` command:
+
+```
+REVOKE SELECT, INSERT, UPDATE
+ON TABLE employees
+FROM HR_department;
+```
+
+## Default Privileges
+
+When a new object is created, it usually inherits default privileges based on the current user or the owner of the schema containing the object. To modify these default privileges, you can use the `ALTER DEFAULT PRIVILEGES` command. This allows you to define which privileges should be granted to which roles by default when an object is created.
+
+For example, to grant SELECT, INSERT, and UPDATE privileges to the user "HR_department" on all future tables, you can execute the following SQL command:
+
+```
+ALTER DEFAULT PRIVILEGES
+FOR ROLE HR_department
+GRANT SELECT, INSERT, UPDATE ON TABLES TO HR_department;
+```
+
+By understanding and properly applying PostgreSQL object privileges, you can ensure a secure and well-organized access control system for your database objects. Remember to periodically review these privileges and make necessary adjustments to maintain the desired level of security.

src/data/roadmaps/postgresql-dba/content/106-postgresql-security-concepts/101-advanced-topics/100-row-level-security.md

@@ -1 +1,74 @@
-# Row level security
+# Row-Level Security
+
+## Row Level Security
+
+Row Level Security (RLS) is a powerful feature introduced in PostgreSQL 9.5, which allows you to control access to individual rows in a database table based on specific policies. This level of granularity can help ensure that only authorized users can access, update or delete certain records in a table.
+
+### When to use RLS
+
+Row Level Security is suitable when you want to provide access control to a more granular level, such as:
+
+- Multi-tenant applications where each tenant should only see and modify their own data.
+- Applications dealing with sensitive information, requiring fine-grained access control to specific rows in a table.
+
+### Steps to Implement Row Level Security
+
+1. **Enable RLS for a table**
+
+   To enable RLS for a table, you use the `ALTER TABLE` command with the `ENABLE ROW LEVEL SECURITY` option.
+
+   ```
+   ALTER TABLE table_name ENABLE ROW LEVEL SECURITY;
+   ```
+
+2. **Create a security policy**
+
+   A security policy is a set of rules that define the conditions for access, modification or deletion of a row within the target table. You use the `CREATE POLICY` command to define a security policy.
+
+   ```
+   CREATE POLICY policy_name
+   ON table_name
+   [USING (predicate_expression)]
+   [WITH CHECK (predicate_expression)];
+   ```
+
+   - `USING (predicate_expression)`: Defines the condition for selecting rows (read access).
+   - `WITH CHECK (predicate_expression)`: Defines the condition for updating or deleting rows (write access).
+
+3. **Apply the security policy**
+
+   A security policy can be applied globally, per role or per user. You use the `ALTER TABLE` command with the `FORCE ROW LEVEL SECURITY` option to apply the policy.
+
+   ```
+   ALTER TABLE table_name FORCE ROW LEVEL SECURITY;
+   ```
+
+### Example
+
+Let's consider that we have a `invoices` table that contains invoice records for different customers. Suppose we want to restrict access to specific invoices by customer.
+
+1. Enable RLS for the `invoices` table:
+
+   ```
+   ALTER TABLE invoices ENABLE ROW LEVEL SECURITY;
+   ALTER TABLE invoices FORCE ROW LEVEL SECURITY;
+   ```
+
+2. Create a security policy:
+
+   ```
+   CREATE POLICY customer_access_policy
+   ON invoices
+   USING (customer_id = get_current_customer_id())
+   WITH CHECK (customer_id = get_current_customer_id());
+   ```
+
+   Here, we create a policy `customer_access_policy` with a predicate expression that checks if the `customer_id` matches the current customer's ID. The `get_current_customer_id()` function should be created to return the ID of the currently logged in customer.
+
+With this example, we have successfully implemented Row Level Security on the `invoices` table to ensure that customers only have access to their own invoices.
+
+### Limitations & Precautions
+
+- RLS policies are transparent to the end user and run behind the scenes, which means that a user may not be aware of the policy affecting the query results.
+- Be cautious when using `GRANT ALL` privileges on a table with enabled RLS. This will give a user access to not only the data, but also the ability to disable or alter the security policy.
+- RLS policies will only protect sensitive data if they're well-designed and thoughtful. If you're dealing with highly sensitive information, consider using additional security measures like encryption or database schema separation.

src/data/roadmaps/postgresql-dba/content/106-postgresql-security-concepts/101-advanced-topics/101-selinux.md

@@ -1 +1,42 @@
-# Selinux
+# SELinux
+
+## Summary: SELinux
+
+In this section, we will discuss **SELinux** (Security-Enhanced Linux), a mandatory access control (MAC) security subsystem in the Linux kernel that enhances the overall security of a system. It is crucial for PostgreSQL DBAs to be familiar with SELinux, as it adds an extra layer of protection to the data.
+
+### Introduction to SELinux
+
+SELinux is a security enhancement module integrated into the Linux kernel, developed by the National Security Agency (NSA). This security module implements MAC policies through the power of the Linux kernel, allowing you to define fine-grained access controls for various system entities such as users, files, applications, and network ports.
+
+### SELinux with PostgreSQL
+
+SELinux offers great value to PostgreSQL DBAs, as it ensures the protection of your valuable database in the event of an intrusion or misconfiguration. By default, SELinux policies are already configured for PostgreSQL with tight security and can be found in the SELinux policy package.
+
+The policies work by confining the PostgreSQL process to a separate security context, allowing for the fine-grained customization of access rights. This means that even if an attacker exploits the PostgreSQL process, they will be limited to the access restrictions set by the SELinux policy, thus preventing further system compromise.
+
+### Configuring SELinux for PostgreSQL
+
+SELinux operates in three states:
+
+1. Enforcing: SELinux is enabled and enforces its policies.
+2. Permissive: SELinux is enabled, but merely logs policy violations and does not enforce them.
+3. Disabled: SELinux is completely disabled.
+
+To check the current state and mode of SELinux, use the following command:
+
+```bash
+sestatus
+```
+
+Ideally, you should have SELinux in the enforcing mode for optimal security. If you need to change the state or mode of SELinux, edit the `/etc/selinux/config` file and restart your system.
+
+Some useful SELinux commands and tools for troubleshooting or configuring policies include:
+
+- `ausearch`: Search and generate reports based on SELinux logs.
+- `audit2allow`: Generate SELinux policy rules from log entries.
+- `semanage`: Configure SELinux policies and manage different components.
+- `sealert`: Analyze log events and suggest possible solutions.
+
+### Conclusion
+
+As a PostgreSQL DBA, understanding and properly configuring SELinux is crucial to maintain the security of your database systems. Take the time to learn more about SELinux and its policies to ensure that your PostgreSQL databases are well-protected.

src/data/roadmaps/postgresql-dba/content/106-postgresql-security-concepts/101-advanced-topics/index.md

@@ -1 +1,69 @@
-# Advanced topics
+# Advanced Topics
+
+# PostgreSQL DBA Guide: Advanced Security Concepts
+
+PostgreSQL, as a powerful database management system, offers various advanced security features that help Database Administrators (DBAs) protect the integrity, confidentiality, and availability of data. In this section, we will discuss some of the advanced security concepts that supplement earlier covered topics.
+
+## Table of Contents
+
+- [Row-level Security (RLS)](#row-level-security)
+- [Encryption](#encryption)
+  - [Data Encryption](#data-encryption)
+  - [Encryption in Transit](#encryption-in-transit)
+- [Auditing](#auditing)
+
+<a name="row-level-security"></a>
+### Row-level Security (RLS)
+
+PostgreSQL allows you to define and enforce policies that restrict the visibility and/or modification of rows in a table, depending on the user executing the query. With row-level security, you can implement fine-grained access control to protect sensitive data or comply with data privacy regulations.
+
+To use row-level security, follow these steps:
+
+1. Enable RLS for a specified table using `ALTER TABLE ... FORCE ROW LEVEL SECURITY`.
+2. Define policies that restrict access to rows, based on user privileges or the content of specific columns.
+3. Optionally, enable or disable RLS policies for specific users or roles.
+
+For more information on RLS, refer to the [official PostgreSQL documentation](https://www.postgresql.org/docs/current/ddl-rowsecurity.html).
+
+<a name="encryption"></a>
+### Encryption
+
+<a name="data-encryption"></a>
+#### Data Encryption
+
+PostgreSQL supports data-at-rest encryption through an extension called `pgcrypto`. This extension provides a suite of functions for generating hashes, cryptographically secure random numbers, and symmetric or asymmetric encryption/decryption.
+
+To use `pgcrypto`, follow these steps:
+
+1. Install the `pgcrypto` extension using `CREATE EXTENSION pgcrypto;`
+2. Implement encryption/decryption functions in your application, such as `pgp_sym_encrypt`, `pgp_sym_decrypt`, `digest`, and others.
+3. Securely manage encryption keys, by either using your application or third-party key management solutions.
+
+For more information on `pgcrypto`, refer to the [official PostgreSQL documentation](https://www.postgresql.org/docs/current/pgcrypto.html).
+
+<a name="encryption-in-transit"></a>
+#### Encryption in Transit
+
+To protect data in transit between the PostgreSQL server and clients, you can configure SSL/TLS encryption for all connections. By encrypting communication, you mitigate the risk of unauthorized interception or eavesdropping.
+
+To configure SSL/TLS, follow these steps:
+
+1. Enable SSL in the PostgreSQL configuration file `postgresql.conf` by setting `ssl` to `on`.
+2. Generate a certificate and private key for the server.
+3. Optionally, configure client certificate authentication for stronger security.
+4. Restart the PostgreSQL service to apply the changes.
+
+For more information on configuring SSL/TLS, refer to the [official PostgreSQL documentation](https://www.postgresql.org/docs/current/ssl-tcp.html).
+
+<a name="auditing"></a>
+### Auditing
+
+Proper auditing is critical for protecting sensitive data and ensuring compliance with data protection regulations. PostgreSQL provides various logging and monitoring features that allow you to collect and analyze server activity data.
+
+- Enable query logging by configuring `log_statement` and `log_duration` in the `postgresql.conf` file.
+- To track changes to specific tables, use the `pgaudit` extension, which allows you to generate detailed auditing logs containing SQL statements and their results.
+- Monitor logs and other system metrics to detect and respond to suspicious activities or performance issues.
+
+For more information on auditing in PostgreSQL, refer to the [official PostgreSQL documentation](https://www.postgresql.org/docs/current/runtime-config-logging.html) and the [`pgaudit` project page](https://www.pgaudit.org/).
+
+By understanding and implementing these advanced security concepts, you can significantly improve the security of your PostgreSQL environment and protect sensitive data from unauthorized access, tampering, or exposure.

src/data/roadmaps/postgresql-dba/content/106-postgresql-security-concepts/102-authentication-models.md

@@ -1 +1,68 @@
-# Authentication models
+# Authentication Models
+
+## Authentication Models in PostgreSQL Security
+
+When securing your PostgreSQL database, it's critical to understand and implement proper authentication models. Authentication refers to the process of confirming the identity of a user attempting to access the database. In this section, we'll discuss the various authentication methods available in PostgreSQL and how to configure them appropriately.
+
+### Trust Authentication
+
+Trust authentication allows users to connect to the database without providing a password. This method is only suitable for situations where the database server is secure and accessible only by trusted users, such as on a local network. To use trust authentication, edit the `pg_hba.conf` file and change the authentication method to `trust`:
+
+```
+# TYPE  DATABASE  USER  ADDRESS  METHOD
+local   all       all           trust
+```
+
+### Password Authentication
+
+Password authentication requires users to provide a password when connecting to the database. There are three types of password authentication methods available in PostgreSQL: plain, md5, and scram-sha-256.
+
+- **Plain**: This method requires plaintext passwords which are not recommended due to security issues.
+- **MD5**: This method hashes the password using the MD5 algorithm, providing a more secure alternative to plain passwords.
+- **SCRAM-SHA-256**: This is the most secure password authentication method in PostgreSQL, using the SCRAM-SHA-256 algorithm for password hashing.
+
+To enable one of these password authentication methods, change the `METHOD` in the `pg_hba.conf` file:
+
+```
+# TYPE  DATABASE  USER  ADDRESS  METHOD
+local   all       all           md5
+```
+
+Replace `md5` with `scram-sha-256` for enhanced security.
+
+### Certificate Authentication
+
+This method uses SSL certificates for authentication, with the server verifying a client's certificate before granting access. To enable certificate authentication, configure SSL on both the server and client and set the `METHOD` in the `pg_hba.conf` file to `cert`:
+
+```
+# TYPE  DATABASE  USER  ADDRESS  METHOD
+hostssl all       all   all      cert
+```
+
+Ensure that the client certificate is signed by a trusted certificate authority, and that the server is configured to trust this authority by adding it to the `ssl_ca_file` configuration parameter.
+
+### GSSAPI and SSPI Authentication
+
+GSSAPI and SSPI are external authentication protocols used in Kerberos and Windows Active Directory environments, respectively. These methods allow the PostgreSQL server to integrate with existing identity management systems.
+
+To configure one of these authentication methods, set the `METHOD` in the `pg_hba.conf` file to either `gss` (for GSSAPI) or `sspi` (for SSPI):
+
+```
+# TYPE  DATABASE  USER  ADDRESS  METHOD
+host    all       all   all      gss
+```
+
+Replace `gss` with `sspi` for SSPI authentication. Additional configuration may be required to integrate with your specific identity management system.
+
+### LDAP Authentication
+
+LDAP (Lightweight Directory Access Protocol) is an application protocol used to access directory services over a network. PostgreSQL supports LDAP authentication, allowing users to authenticate against an LDAP server.
+
+To enable LDAP authentication, set the `METHOD` in the `pg_hba.conf` file to `ldap` and provide the LDAP server information:
+
+```
+# TYPE  DATABASE  USER  ADDRESS  METHOD  [OPTIONS]
+host    all       all   all      ldap    ldapserver=ldap.example.com ldapbasedn="ou=users,dc=example,dc=com"
+```
+
+This is just a brief summary of the various authentication models supported by PostgreSQL. Depending on your specific requirements, you may need to further configure and fine-tune the authentication methods to best fit your environment. For further information and details, refer to the [official PostgreSQL documentation](https://www.postgresql.org/docs/current/auth-methods.html).

src/data/roadmaps/postgresql-dba/content/106-postgresql-security-concepts/103-roles.md

@@ -1 +1,55 @@
-# Roles
+# Roles
+
+# PostgreSQL Security Concepts: Roles
+
+In this section of the guide, we will dive into the concept of roles in PostgreSQL, which is a crucial aspect of ensuring adequate security measures in managing your database. Roles play a significant part in managing user access, privileges, and overall authentication within PostgreSQL.
+
+## Introduction to Roles
+
+A role in the context of PostgreSQL can be considered as a user, a group, or both depending on how it is configured. Roles are essentially a way to manage the database objects (like tables, schemas, and more) and the different permissions associated with those objects. PostgreSQL does not distinguish between users and groups, so 'roles' is a collective term used to represent them.
+
+Roles can be created, altered, and dropped as per requirements, and their attributes or capabilities can be modified according to specific purposes. In PostgreSQL, there are two types of roles:
+
+- **Login roles**: These roles have the ability to connect to the database and act as a traditional "user" with a username and password for authentication.
+- **Group roles**: These roles are used primarily for managing privileges among multiple users.
+
+## Key Attributes of Roles
+
+There are several attributes associated with a role that can help you define its capabilities and permissions. Some of the main attributes are:
+
+- **LOGIN / NOLOGIN**: Determines whether a role can log into the database or not. LOGIN allows the role to connect, while NOLOGIN prevents connection.
+- **SUPERUSER / NOSUPERUSER**: Specifies if a role has superuser privileges. A superuser can bypass all access restrictions within the database.
+- **CREATEDB / NOCREATEDB**: Identifies if a role can create new databases. CREATEDB grants permission, while NOCREATEDB denies it.
+- **CREATEROLE / NOCREATEROLE**: Specifies whether a role can create, alter, or drop other roles. CREATEROLE allows this, while NOCREATEROLE does not.
+- **INHERIT / NOINHERIT**: Defines whether a role inherits privileges from the roles it is a member of. INHERIT enables inheritance, while NOINHERIT disables it.
+- **REPLICATION / NOREPLICATION**: Determines if a role can initiate streaming replication or create new replication slots. REPLICATION grants the privilege, while NOREPLICATION denies it.
+
+## Managing Roles
+
+To manage roles in PostgreSQL, you can use the following SQL commands:
+
+- **CREATE ROLE**: Creates a new role with the specified attributes.
+- **ALTER ROLE**: Modifies the attributes or capabilities of an existing role.
+- **DROP ROLE**: Deletes an existing role from the database.
+- **GRANT**: Grants privileges on a specific database object to a role.
+- **REVOKE**: Revokes previously granted privileges from a role.
+
+## Example: Creating and managing a role
+
+To create a new login role with the ability to create databases:
+
+```sql
+CREATE ROLE myuser WITH LOGIN CREATEDB PASSWORD 'mypassword';
+```
+
+To grant myuser the ability to SELECT, INSERT, UPDATE, and DELETE data in a specific table:
+
+```sql
+GRANT SELECT, INSERT, UPDATE, DELETE ON mytable TO myuser;
+```
+
+## Conclusion
+
+Roles are an essential part of PostgreSQL security as they help manage user access, privileges, and authentication. Understanding the different role attributes and their functions is vital for proper administration and management of your PostgreSQL database.
+
+By learning to create, modify, and use roles, you will be better equipped to ensure the security and proper functioning of your PostgreSQL DBA tasks.

src/data/roadmaps/postgresql-dba/content/106-postgresql-security-concepts/104-pg-hba-conf.md

@@ -1 +1,49 @@
-# Pg hba conf
+# pg_hba.conf
+
+## pg_hba.conf
+
+The `pg_hba.conf` file is a crucial element in PostgreSQL security. It controls the client authentication process, defining the access rules for users connecting to the database. It is located in the PostgreSQL data directory, typically `/var/lib/pgsql/xx/main/pg_hba.conf`.
+
+### Access control in pg_hba.conf
+
+To manage access control, `pg_hba.conf` uses entries that define a set of rules for each user, combining the following:
+
+- **Connection type**: Determines whether the connection is local or remote. For local connections, use "`local`." For remote connections, use "`host`," "`hostssl`," or "`hostnossl`."
+
+- **Database**: Specifies the database(s) the user can access. You can use specific database names or keywords like "`all`," "`sameuser`," or "`samerole`."
+
+- **User**: Identifies the user(s) allowed to access the database. You can use specific usernames or keywords like "`all`."
+
+- **Address**: Specifies the IP address or subnet (for remote connections) or local UNIX domain sockets (for local connections) that the user can access.
+
+- **Authentication method**: Defines the required authentication method, such as "`trust`," "`md5`," "`password`," "`gss`," "`sspi`," "`ident`," "`peer`," "`pam`," "`ldap`," "`radius`," or "`cert`."
+
+### Example of a pg_hba.conf file
+
+```
+# Allow local connections from any user to any database
+local   all         all                     trust
+
+# Allow remote connections from the "example_app" user to the "exampledb" database
+host    exampledb   example_app   192.168.1.0/24    md5
+
+# Allow SSL connections from the "replica" user to the "replication" database
+hostssl replication replica       ::/0              cert clientcert=1
+```
+
+### Modifying pg_hba.conf
+
+To change the authentication settings, open the `pg_hba.conf` file with your preferred text editor and make the necessary adjustments. It is essential to maintain the correct format, as invalid entries can compromise the database's security or prevent user connections.
+
+Once you've made changes to the file, save it and reload the PostgreSQL server for the changes to take effect, using the following command:
+
+```
+sudo systemctl reload postgresql
+```
+
+### Best practices
+
+- Review the default PostgreSQL configuration and ensure you modify it to follow your organization's security rules.
+- Keep the `pg_hba.conf` file under version control to track changes and help with auditing.
+- Use the least privilege principle – grant only the necessary access to users to minimize the risk of unauthorized actions.
+- Use `hostssl` to enforce secure SSL connections from remote clients.

src/data/roadmaps/postgresql-dba/content/106-postgresql-security-concepts/105-ssl-settings.md

@@ -1 +1,62 @@
-# Ssl settings
+# SSL Settings
+
+## SSL Settings in PostgreSQL
+
+Secure Sockets Layer (SSL) is a protocol that provides a secure channel for communication between a client and a server. It ensures that all data exchanged between the server and the client is encrypted and authenticated to avoid eavesdropping and tampering. In PostgreSQL, SSL can be enabled and configured to enhance the security of your database. This section will provide you with a brief summary of SSL settings in PostgreSQL.
+
+### Enabling SSL
+
+To enable SSL in PostgreSQL, you need to set the `ssl` configuration parameter to `on` in the `postgresql.conf` file.
+
+```bash
+ssl = on
+```
+
+After enabling SSL, you need to provide the server's SSL key and certificate, which can either be a self-signed certificate or a certificate issued by a trusted Certificate Authority (CA). By default, PostgreSQL looks for these files in the data directory with the names `server.key` and `server.crt`.
+
+### SSL Certificates and Keys
+
+Here are the steps to create a self-signed certificate and a private key for the server:
+
+1. Generate a private key using the command below:
+
+   ```bash
+   openssl genpkey -algorithm RSA -out server.key -pkeyopt rsa_keygen_bits:2048
+   ```
+
+2. Set proper permissions:
+
+   ```bash
+   chmod 600 server.key
+   ```
+
+3. Create a self-signed certificate:
+
+   ```bash
+   openssl req -new -x509 -days 365 -key server.key -out server.crt -subj "/C=XX/ST=XX/L=XX/O=XX/CN=XX"
+   ```
+
+### Client Verification
+
+PostgreSQL allows you to specify the level of SSL security for client connections using the `sslmode` setting in the `pg_hba.conf` file. Available options are:
+
+- `disable`: No SSL.
+- `allow`: Choose SSL if the server supports it, otherwise a non-SSL connection.
+- `prefer`: (default) Choose SSL if the server supports it, but allow non-SSL connections.
+- `require`: SSL connections only.
+- `verify-ca`: SSL connections, and verify that the server certificate is issued by a trusted CA.
+- `verify-full`: SSL connections, verify CA, and check that the server hostname matches the certificate.
+
+### Certificate Revocation Lists (CRL)
+
+To revoke a certificate, add it to the Certificate Revocation List (CRL). Upon connection, the server checks if the client's certificate is present in the CRL. You can configure PostgreSQL to use a CRL by setting the `ssl_crl_file` configuration parameter:
+
+```bash
+ssl_crl_file = 'path/to/your/crl.pem'
+```
+
+To create and update a CRL, you can use the `openssl` tool.
+
+### Summary
+
+Understanding SSL settings in PostgreSQL is vital for ensuring the security of your database. Enabling SSL, creating certificates and keys, configuring client verification levels, and managing certificate revocations will help you keep your connections and data secure.

src/data/roadmaps/postgresql-dba/content/106-postgresql-security-concepts/index.md

@@ -1 +1,38 @@
-# Postgresql security concepts
+# Postgres Security Concepts
+
+# PostgreSQL Security Concepts
+
+This section of the guide covers the essential security concepts when working with PostgreSQL. Security is a vital aspect of any database administrator's role, as it ensures the integrity, availability, and confidentiality of the data stored within the system. In this summary, we'll cover the key PostgreSQL security concepts such as authentication, authorization, and encryption.
+
+## 1. Authentication
+
+Authentication is the process of verifying the identity of a user or application trying to access the database system. PostgreSQL supports various authentication methods, including:
+
+  - Password (`password` and `md5`): Users provide a plaintext or MD5-hashed password.
+  - Peer (`peer`): The database user is determined by the operating system user, but it is only supported for local connections on UNIX-based systems.
+  - Ident (`ident`): Works similarly to `peer`, but it uses an external authentication server.
+  - GSSAPI (`gss`): Utilizes the Generic Security Services Application Program Interface for authentication.
+  - SSL Certificates (`cert`): Requires users to provide a valid client-side SSL certificate for authentication.
+  
+  Configure these authentication methods in the `pg_hba.conf` file of your PostgreSQL installation.
+
+## 2. Authorization
+
+Once a user has been authenticated, the next step is determining what actions they are allowed to perform within the database system. PostgreSQL uses a combinations of privileges and roles to control the user's access and operations. Two central concepts in PostgreSQL authorization are:
+
+  - Roles: A role can be a user, group or both. Roles are used to define the permissions a user or a group has within the database.
+  - Privileges: These are the specific actions that a role is authorized to perform, such as creating a table or modifying data.
+
+Use the SQL commands `CREATE ROLE`, `ALTER ROLE`, and `DROP ROLE` to manage roles. Assign privileges using the commands `GRANT` and `REVOKE`.
+
+## 3. Encryption
+
+Data encryption provides an additional layer of security, protecting sensitive information from unauthorized access. PostgreSQL supports encryption in multiple ways:
+
+  - Data at rest: Use file-system level encryption, third-party tools, or PostgreSQL's built-in support for Transparent Data Encryption (TDE) to encrypt data as it is stored on disk.
+  - Data in motion: Enable SSL/TLS encryption to secure the connections between client applications and the PostgreSQL server.
+  - Column-level encryption: Encrypt specific, sensitive columns within a table to add an extra layer of protection for that data.
+
+To configure SSL/TLS encryption for client connections, update the `postgresql.conf` file and provide the appropriate certificate files.
+
+By understanding and implementing these security concepts appropriately, you can ensure that your PostgreSQL instance is safeguarded against unauthorized access, data breaches, and other potential security threats.

src/data/roadmaps/postgresql-dba/content/107-postgresql-infrastructure-skills/100-replication/100-logical-replication.md

@@ -1 +1,55 @@
-# Logical replication
+# Logical Replication
+
+## Logical Replication
+
+Logical replication is a method of replicating data and database objects (such as tables, indexes, and sequences) from one PostgreSQL database to another. This replication method is based on the logical decoding of the database's write-ahead log (WAL). Logical replication provides more flexibility than physical replication and is suitable for replicating a specific set of tables or a subset of the data in the source database.
+
+### Advantages
+
+* **Selective replication**: Unlike physical replication, logical replication allows you to choose specific tables that will be replicated to the subscriber. This can save bandwidth and resources, as you don't need to replicate the entire database.
+* **Different PostgreSQL versions**: With logical replication, you can replicate data between databases running different PostgreSQL versions, provided that the publisher is running a version equal to or older than the subscriber.
+* **Schema changes**: Logical replication supports applying schema changes on the subscriber without breaking replication. However, some schema changes may still require conflicts to be resolved manually.
+
+### Configuration
+
+To set up logical replication, you need to perform the following steps:
+
+1. **Enable logical replication**: In the `postgresql.conf` file, set the `wal_level` to `logical`:
+
+   ```sh
+   wal_level = logical
+   ```
+
+   Also, increase `max_replication_slots` and `max_wal_senders` according to the number of subscribers you want to support.
+
+2. **Create the replication role**: Create a new user with `REPLICATION` and `LOGIN` privileges. This user will be used to authenticate the replication process on the publisher.
+
+   ```sql
+   CREATE ROLE replication_user WITH REPLICATION LOGIN PASSWORD 'your-password';
+   ```
+
+3. **Configure authentication**: Add a new entry in the `pg_hba.conf` file for the replication user. This entry should be added on both the publisher and subscriber.
+
+   ```sh
+   host replication replication_user publisher/subscriber-ip/32 md5
+   ```
+
+4. **Add the publications**: On the publisher database, create a publication for the tables you want to replicate.
+
+   ```sql
+   CREATE PUBLICATION my_publication FOR TABLE table1, table2;
+   ```
+
+5. **Add the subscriptions**: On the subscriber database, create a subscription to consume data from the publications.
+
+   ```sql
+   CREATE SUBSCRIPTION my_subscription CONNECTION 'host=publisher-host user=replication_user password=your-password dbname=source-dbname' PUBLICATION my_publication;
+   ```
+
+After these steps, logical replication should be functional, and any changes made to the publisher's tables will be replicated to the subscriber's tables.
+
+### Monitoring and Troubleshooting
+
+To monitor the performance and status of logical replication, you can query the `pg_stat_replication` and `pg_stat_subscription` views on the publisher and subscriber databases, respectively. If you encounter any issues, check the PostgreSQL logs for more detailed information.
+
+Keep in mind that logical replication may have some limitations, such as not replicating DDL changes, large objects, or truncation. Always test your configuration thoroughly and plan for necessary manual interventions when needed.

src/data/roadmaps/postgresql-dba/content/107-postgresql-infrastructure-skills/100-replication/101-streaming-replication.md

@@ -1 +1,73 @@
-# Streaming replication
+# Streaming Replication
+
+### Streaming Replication
+
+Streaming Replication allows a primary PostgreSQL database server to transmit real-time changes (also known as WAL - Write Ahead Log) to one or more secondary (standby) servers. This process increases availability and provides redundancy for the database system. 
+
+#### Advantages of Streaming Replication
+
+- **High availability**: Standby servers can immediately take over if the primary server fails, minimizing downtime.
+- **Load balancing**: Read-only queries can be distributed among standby servers, thus improving query performance.
+- **Data protection**: Data is automatically backed up on standby servers, reducing the risk of data loss.
+
+#### Setting up Streaming Replication
+
+1. **Configure the primary server**: Enable replication by modifying some configuration parameters in the `postgresql.conf` and `pg_hba.conf` files.
+
+In `postgresql.conf`, set the following parameters:
+
+```
+wal_level = replica
+max_wal_senders = 3
+wal_keep_segments = 32
+```
+
+In `pg_hba.conf`, add the following line to allow connections from standby server's IP address:
+
+```
+host replication replicator [standby_ip] md5
+```
+
+2. **Create replication user**: On the primary server, create a new role with the `REPLICATION` privilege:
+
+```sql
+CREATE ROLE replicator WITH REPLICATION PASSWORD 'your-password' LOGIN;
+```
+
+3. **Transfer initial data to the standby server**: On the primary server, use the `pg_basebackup` command to transfer the initial data to the standby server:
+
+```bash
+pg_basebackup -h [standby_host] -D [destination_directory] -U replicator -P --wal-method=stream
+```
+
+4. **Configure the standby server**: Create a `recovery.conf` file in the PostgreSQL data directory on the standby server with the following content:
+
+```
+standby_mode = 'on'
+primary_conninfo = 'host=[primary_host] port=5432 user=replicator password=your-password'
+trigger_file = '/tmp/trigger'
+```
+
+5. **Start PostgreSQL on the standby server**: Start PostgreSQL on the standby server to begin streaming replication.
+
+#### Monitoring Streaming Replication
+
+You can monitor the streaming replication status by running the following query on the primary server:
+
+```sql
+SELECT * FROM pg_stat_replication;
+```
+
+The query returns information about the connected standby servers, such as application_name, client_addr, and state.
+
+#### Performing Failover
+
+In case of primary server failure, you can promote a standby server to become the new primary server by creating the trigger file specified in the `recovery.conf` file:
+
+```bash
+touch /tmp/trigger
+```
+
+Once the failover is complete, you will need to reconfigure the remaining standby servers to connect to the new primary server.
+
+That's a brief summary of streaming replication in PostgreSQL. You can dive deeper into this topic by exploring the [official PostgreSQL documentation](https://www.postgresql.org/docs/current/warm-standby.html#STREAMING-REPLICATION).

src/data/roadmaps/postgresql-dba/content/107-postgresql-infrastructure-skills/100-replication/index.md

@@ -1 +1,46 @@
-# Replication
+# Replication
+
+## Replication in PostgreSQL
+
+Replication involves creating and maintaining multiple copies of a database to ensure high availability and data redundancy. This plays a crucial role in the recovery process during system crashes, hardware failures, or disasters while keeping business operations running smoothly. PostgreSQL offers various techniques and tools for replication, which can be grouped into two categories: physical and logical replication.
+
+### Physical Replication
+
+Physical replication refers to block-level copying of data from the primary server to one or more standby servers. The primary and standby servers have an identical copy of the database cluster. This is also known as binary replication.
+
+1. **Streaming Replication:** Streaming replication enables a standby server to stay up-to-date with the primary server by streaming Write-Ahead Logging (WAL) records. Standby servers pull the WAL records from the primary server, enabling real-time replication.
+
+Pros:
+  - It provides almost real-time replication with low-latency.
+  - It supports synchronous and asynchronous replication modes.
+  - Standby servers can be used for read-only queries, thus reducing the load on the primary server.
+  
+Cons:
+  - It replicates the entire database cluster, providing no column or row-level filtering.
+  - It does not facilitate bidirectional replication, which requires additional tools like Slony or SymmetricDS.
+
+2. **File-based Replication:** This technique involves copying the actual data files to set up replication instead of streaming WAL records. One of the most common methods is using `rsync` with a custom script or scheduled `cron` jobs.
+
+### Logical Replication
+
+Logical replication involves copying only specific data (tables or columns) between databases, allowing more granular control over what to replicate. It is implemented using logical decoding and replication slots.
+
+1. **Publication and Subscription Model:** PostgreSQL 10 introduced the built-in logical replication feature based on the publish-subscribe pattern. One or more tables are marked for replication with a publication, and the target database subscribes to this publication to receive the data changes.
+
+Pros:
+  - Offers row and column-level filtering.
+  - Supports selective replication of specific tables between databases, reducing replication overhead.
+  - No need for external tools or extensions.
+
+Cons:
+  - Not all data types and DDL statements are supported in logical replication.
+  - Doesn't automatically replicate table schema changes, which requires manual intervention.
+
+### Choosing the right replication technique
+
+The choice between physical and logical replication in your PostgreSQL infrastructure depends on your business requirements:
+
+- For a completely identical database cluster and low-latency replication, go with **physical replication**.
+- For granular control over what data to replicate, and if you want to replicate only specific tables or a subset of the data between databases, choose **logical replication**.
+
+Considering both the replication types' pros and cons, you should choose the approach that best fits your PostgreSQL infrastructure and business needs.

src/data/roadmaps/postgresql-dba/content/107-postgresql-infrastructure-skills/100-resource-usage-provisioing-capacity-planning.md

@@ -1 +1,34 @@
-# Resource usage provisioing capacity planning
+# Resource Usage and Provisioning, Capacity Planning
+
+
+## Resource Usage, Provisioning, and Capacity Planning
+
+As a PostgreSQL DBA, it's crucial to understand resource usage, provisioning, and capacity planning to ensure that your database infrastructure operates smoothly and efficiently. This section provides a brief summary of the topic.
+
+### Resource Usage
+
+Resource usage refers to the amount of computer hardware and software resources (CPU, memory, disk, and I/O) a PostgreSQL database consumes during operation. It's essential to monitor resource usage to identify potential problems, optimize database performance, and also prevent unwanted downtimes. When monitoring resource usage, you should focus on key aspects such as:
+
+- CPU usage: The CPU time allocated to PostgreSQL processes
+- Memory usage: The RAM memory consumed by PostgreSQL
+- Disk space usage: The storage capacity consumed by table/index files and transaction logs
+- I/O activity: The rate of read/write operations on the disk
+
+### Provisioning
+
+Provisioning involves allocating the necessary resources to your PostgreSQL instances, based on their projected requirements. This commonly includes allocating suitable compute, storage, and network capacities. Some essential provisioning aspects include:
+
+- Determining hardware requirements: Ensuring the required CPU, memory, and disk capacities are available and matched to the workloads
+- Storage management: Properly configuring storage settings, including RAID configurations, file systems, and partitioning
+- Network considerations: Configuring your network to have sufficient bandwidth and latency to handle database client connections and replication
+
+### Capacity Planning
+
+Capacity planning is the practice of estimating future resource requirements and planning for the anticipated growth of your PostgreSQL instances. Effective capacity planning ensures that your infrastructure can scale smoothly to support increasing workloads. Some aspects to consider when capacity planning include:
+
+- Forecasting growth: Use historical data and expected usage patterns to predict your database's growth and resource requirements
+- Scaling strategies: Plan for horizontal (adding more instances) or vertical (adding more resources, e.g., CPU or memory) scaling, based on your workload characteristics
+- Load balancing: Design strategies to distribute workload evenly across multiple database instances
+- Monitoring and alerting: Implement monitoring solutions to track resource usage and set up alerts for critical thresholds, allowing you to take proactive actions when needed
+
+In summary, understanding resource usage, provisioning, and capacity planning is an essential part of managing a PostgreSQL database infrastructure. By effectively monitoring resource usage, allocating the required resources, and planning for future growth, you can ensure that your database remains performant and reliable while minimizing costs and disruptions.

src/data/roadmaps/postgresql-dba/content/107-postgresql-infrastructure-skills/101-connection-pooling/100-pg-bouncer.md

@@ -1 +1,51 @@
-# Pg bouncer
+# PgBouncer
+
+# PgBouncer
+
+PgBouncer is a lightweight connection pooler for PostgreSQL databases. Its main function is to reduce the performance overhead caused by opening new connections to the database by reusing existing connections. This is especially important for applications with a high number of concurrent connections, as PostgreSQL's performance can degrade with too many connections.
+
+## Features
+
+- **Connection pooling**: PgBouncer maintains a pool of active connections and efficiently assigns these connections to incoming client requests, minimizing the overhead of establishing new connections.
+- **Transaction pooling**: In this mode, clients can only run a single transaction at a time, but connection reuse is maximized, which can greatly improve performance in scenarios with high levels of concurrency.
+- **Statement pooling**: This mode only pools connections that are outside of a transaction, allowing clients to run multiple transactions in parallel while still improving connection reuse.
+- **Session pooling**: Each client connection is directly mapped to a dedicated PostgreSQL connection, though unused connections are still returned to the pool for use by other clients.
+- **TLS/SSL support**: PgBouncer supports encrypted connections, both from clients and to the PostgreSQL server.
+- **Authentication**: Allows for flexible authentication methods such as plaintext, MD5, or more advanced options like client certificates.
+- **Low resource usage**: Due to its lightweight design, PgBouncer has minimal memory and CPU requirements, making it suitable for running alongside your application or on a central server.
+
+## Usage
+
+1. **Installation**: PgBouncer can be installed from the package repositories of most major Linux distributions, or compiled from source.
+
+2. **Configuration**: To configure PgBouncer, you need to create a `pgbouncer.ini` file containing the necessary settings, such as the connection details of your PostgreSQL server, the desired pooling mode, and the authentication method.
+
+Example:
+
+```ini
+[databases]
+mydb = host=localhost port=5432 dbname=mydb
+
+[pgbouncer]
+listen_addr = 127.0.0.1
+listen_port = 6432
+auth_type = md5
+auth_file = /etc/pgbouncer/userlist.txt
+pool_mode = transaction
+max_client_conn = 1000
+default_pool_size = 50
+```
+
+3. **Client Configuration**: Clients will need to modify their connection settings to connect to PgBouncer (usually running on a different port) instead of the PostgreSQL server directly.
+
+4. **Monitoring**: PgBouncer provides a virtual `pgbouncer` database, where you can send SQL queries to retrieve connection statistics, active connection pool status, and other runtime information.
+
+## Benefits
+
+By using PgBouncer, you can:
+
+- Improve the performance and stability of your application by reusing database connections.
+- Reduce your PostgreSQL server's resource requirements and increase its capacity to handle a higher number of clients.
+- Simplify client connection management by having a central connection pooler.
+
+Overall, PgBouncer is a valuable tool for PostgreSQL DBA and it's essential for managing high-concurrency applications that require optimal performance and resource efficiency.

src/data/roadmaps/postgresql-dba/content/107-postgresql-infrastructure-skills/101-connection-pooling/101-pg-bouncer-alternatives.md

@@ -1 +1,38 @@
-# Pg bouncer alternatives
+# PgBouncer Alternatives
+
+# Connection Pooling: Alternatives to PgBouncer
+
+Although PgBouncer is a popular and widely-used connection pooling solution for PostgreSQL, it's essential to be aware of some alternatives that you may want to consider for your specific use case. In this section, we will briefly cover three alternatives to PgBouncer and their key features.
+
+## 1. Odoo
+[Odoo](https://www.odoo.com/documentation/14.0/setup/deploy.html#db_maxconn) is an all-in-one management software that includes a connection pooling feature. It is designed specifically for the Odoo application, so it may not be suitable for general-purpose PostgreSQL deployments. However, if you are using Odoo, it's worth considering their built-in pooling solution.
+
+**Key Features:**
+
+- Integrated with Odoo ecosystem
+- Handles connection pooling automatically
+
+## 2. Pgpool-II
+[Pgpool-II](https://www.pgpool.net/mediawiki/index.php/Main_Page) is another connection pooling solution that offers additional features such as load balancing, replication, and parallel query execution. Despite its extra functionality, it may add complexity to your deployment, but could be beneficial for larger or more advanced PostgreSQL setups.
+
+**Key Features:**
+
+- Connection pooling
+- Load balancing
+- Automatic failover and online recovery
+- Replication and parallel query execution
+- Watchdog for high availability
+- Query caching
+
+## 3. Heimdall Data
+[Heimdall Data](https://www.heimdalldata.com/) is a commercial product that offers a full-featured data platform, including a connection pooling solution for PostgreSQL, along with advanced features such as intelligent query caching, load balancing, and more. This product could be an ideal option if you need a comprehensive solution and are willing to invest in a commercial tool.
+
+**Key Features:**
+
+- Connection pooling
+- Intelligent query caching
+- Load balancing
+- Security features such as data masking and SQL injection protection
+- Analytics and monitoring
+
+In conclusion, PgBouncer is a popular, efficient and low-footprint connection pooling solution for PostgreSQL. However, depending on your requirements and use-case, one of the alternatives mentioned above may be more appropriate for your PostgreSQL deployment. Be sure to carefully evaluate each option before making a final decision.

src/data/roadmaps/postgresql-dba/content/107-postgresql-infrastructure-skills/101-connection-pooling/index.md

@@ -1 +1,34 @@
-# Connection pooling
+# Connection Pooling
+
+## Connection Pooling
+
+In this section, we will discuss connection pooling in PostgreSQL, its importance, and some popular connection pooling solutions. Connection pooling plays a significant role in minimizing the overhead associated with establishing and maintaining database connections. 
+
+### Why is Connection Pooling Important?
+
+PostgreSQL uses a process-based architecture. Every session with a PostgreSQL database utilizes one PostgreSQL backend process as long as the connection persists. Establishing a new connection is costly due to the overhead of creating a new process, initializing the memory structures, and performing authentication.
+
+In high-concurrency environments with numerous short-lived connections, the overhead of creating a new connection for each session can increase the latency of operations and degrade performance. Connection pooling addresses these challenges by maintaining a set of connections that can be reused by different clients. This practice reduces the overhead of client connections, improves response times, and optimizes resource usage.
+
+### Popular Connection Pooling Solutions
+
+Several connection pooling solutions are available for PostgreSQL. Some of the most popular ones are:
+
+1. **PgBouncer**: PgBouncer is a lightweight connection pooler designed explicitly for PostgreSQL. Its primary function is to reuse existing connections, thus reducing the overhead of establishing a new connection. PgBouncer supports various pooling modes, such as session pooling, transaction pooling, and statement pooling.
+
+2. **Pgpool-II**: Pgpool-II is a more advanced connection pooler and load balancer. In addition to connection pooling, it provides additional features like connection load balancing, query caching, and high availability via Streaming Replication. It is a powerful tool but may introduce more complexity and overhead than necessary for some use cases.
+
+3. **odyssey**: Odyssey is a high-performance connection pooler and proxy for PostgreSQL. It supports both TCP and UNIX-socket connections and provides request processing, authentication, caching, and monitoring functionalities.
+
+### Choosing the Right Connection Pooling Solution
+
+Selecting the right connection pooling solution depends on the specific needs and infrastructure of your PostgreSQL deployment. It's essential to weigh the benefits and drawbacks of each pooler, considering aspects such as performance impact, ease of deployment, compatibility, and additional features.
+
+To determine the suitability of a connection pooling solution, consider:
+
+- Performance requirements: Evaluate how well the connection pooler performs under your specific workload and connection patterns.
+- Feature set: Assess the additional features provided by the solution, such as load balancing, query caching, or high availability, to see if they align with your use case.
+- Compatibility: Ensure the connection pooling solution is compatible with your PostgreSQL deployment and client libraries.
+- Ease of deployment and maintenance: Evaluate the complexity of installing, configuring, and maintaining the solution in your environment.
+
+Remember that choosing the right connection pooling solution is crucial to maintain optimum database performance and manage resources more efficiently. By gaining a thorough understanding of connection pooling, your PostgreSQL DBA skills will become more robust, allowing you to optimize your deployment's performance and reliability.

src/data/roadmaps/postgresql-dba/content/107-postgresql-infrastructure-skills/102-backup-recovery-tools/100-barman.md

@@ -1 +1,43 @@
-# Barman
+# barman
+
+## Barman - Backup and Recovery Manager for PostgreSQL
+
+_Barman_ (Backup and Recovery Manager) is an open-source administration tool for disaster recovery of PostgreSQL servers. It allows you to perform remote backups of multiple PostgreSQL instances and automate the process. By using Barman, DBAs can manage the backup and recovery of their PostgreSQL databases more effectively and efficiently.
+
+### Features
+
+- **Remote Backup**: Barman can perform remote backups of multiple PostgreSQL servers, reducing the risk of data loss and processing overhead on the production servers.
+
+- **Point-in-Time Recovery**: Barman enables Point-in-Time Recovery (PITR), allowing you to recover data up to a specific transaction or time.
+
+- **Compression and Parallelism**: Barman supports configurable compression and parallelism options for backup and recovery operations.
+
+- **Backup Catalog**: Barman keeps track of all the backups, including metadata, allowing you to easily manage and browse your backup catalog.
+
+- **Incremental Backup**: Barman supports incremental backup, reducing the storage requirements and speeding up the backup process.
+
+- **Retention Policy**: Barman allows you to define retention policies to keep backups within a certain timeframe or number of backups, helping to manage storage space and optimize performance.
+
+- **Backup Verification**: Barman verifies the integrity of backups, automatically checking for data corruption, ensuring data consistency, and providing peace of mind.
+
+- **Granular Monitoring and Reporting**: Barman includes detailed monitoring features and reports to help you stay informed and proactive about the health of your backups.
+
+### Installation and Configuration
+
+You can install Barman using various package managers, such as apt or yum, or from source. Follow the instructions provided in the [official Barman documentation](https://docs.pgbarman.org/#installation) for detailed installation steps.
+
+After installation, you need to configure Barman to work with your PostgreSQL servers. The main configuration file is `/etc/barman.conf`, where you can define global settings and per-server configuration for each PostgreSQL instance. The [official Barman documentation](https://docs.pgbarman.org/#configuration) provides a comprehensive guide for configuring Barman.
+
+### Usage
+
+Barman provides various command-line options to manage your backups and recoveries. Here are some examples of common tasks:
+
+- **Taking a backup**: Use `barman backup SERVER_NAME` to create a new full or incremental backup for a specific PostgreSQL instance.
+
+- **Listing backups**: Use `barman list-backup SERVER_NAME` to list all the available backups for a specific PostgreSQL instance.
+
+- **Recovering a backup**: Use `barman recover --target-time "YYYY-MM-DD HH:MI:SS" SERVER_NAME BACKUP_ID DESTINATION_DIRECTORY` to recover a backup to a specific destination directory up until a certain point in time.
+
+For more examples and a complete list of command-line options, refer to the [official Barman documentation](https://docs.pgbarman.org/#using-barman).
+
+In conclusion, Barman is an essential tool for PostgreSQL DBAs to implement an effective backup and recovery strategy. By automating and optimizing backup processes and providing comprehensive monitoring and reporting features, Barman helps ensure the reliability and stability of your PostgreSQL databases.

src/data/roadmaps/postgresql-dba/content/107-postgresql-infrastructure-skills/102-backup-recovery-tools/101-wal-g.md

@@ -1 +1,36 @@
-# Wal g
+# WAL-G
+
+## WAL-G
+
+WAL-G is an essential backup recovery tool that you should get to know when working with PostgreSQL. At its core, WAL-G is an archiving and recovery tool, designed to efficiently perform continuous archival and disaster recovery in PostgreSQL. It is a Go-based open-source tool written by the Citus team and has gained significant popularity amongst developers.
+
+### Key Features:
+
+- **Delta Backups**: WAL-G creates delta backups, which are incremental and highly efficient. These delta backups consume less storage and reduce backup times, offering a significant advantage over traditional full backups.
+
+- **Compression**: WAL-G compresses the backup files, conserving storage space without losing any data. The compression is highly effective, ensuring minimal storage costs.
+
+- **Point in Time Recovery (PITR)**: WAL-G allows you to perform point-in-time recovery, meaning you can restore your database to a specific point in the past. This is highly valuable as it enables partial recovery of lost data without restoring the entire backup.
+
+- **Encryption**: With WAL-G, you can encrypt your backups using popular encryption tools like GPG or OpenSSL. This additional layer of security ensures that your critical data remains protected.
+
+- **Cloud Storage Support**: WAL-G can be used in conjunction with cloud storage services such as Amazon S3, Google Cloud Storage, or Azure Blob Storage. This opens the door to highly accessible and redundant backup storage options.
+
+- **Performance**: As it's written in Go, WAL-G is a high-performance tool built to work effectively with large-scale databases. WAL-G's backup and restore process has minimal impact on database performance, ensuring a smooth operation.
+
+### Usage:
+
+Using WAL-G is rather straightforward. After installation, you can initiate a base backup with a single command:
+
+```
+wal-g backup-push /path/to/pgdata
+```
+
+When you need to restore a backup, simply run the following commands:
+
+```
+wal-g backup-fetch /path/to/pgdata LATEST
+pg_ctl start
+```
+
+Overall, WAL-G is an indispensable tool for PostgreSQL DBAs. Its ability to perform efficient delta backups, compression, encryption, and point-in-time recovery makes it an excellent choice to manage your database backup and recovery processes.

src/data/roadmaps/postgresql-dba/content/107-postgresql-infrastructure-skills/102-backup-recovery-tools/102-pgbackrest.md

@@ -1 +1,58 @@
-# Pgbackrest
+# pgbackrest
+
+### PgBackRest
+
+[PgBackRest](https://pgbackrest.org/) is an open-source backup and recovery management solution for PostgreSQL databases. It is designed to be easy to use, efficient, and reliable, providing robust and comprehensive functionality for managing database backups.
+
+#### Features
+
+* **Parallel Compression**: PgBackRest compresses backup files in parallel, taking advantage of multiple processors to increase backup speed.
+* **Incremental Backups**: Only the changes since the last backup are stored, reducing storage requirements and speeding up the backup process.
+* **Local/Remote Backups**: You can perform backups on the same machine where the database is running or on a remote machine with minimal configuration.
+* **Backup Archiving and S3 Integration**: Backup files can be archived to external storage such as AWS S3 for additional durability and long-term storage.
+* **Point-In-Time Recovery (PITR)**: Allows you to recover your database to a specific point in time, providing fine-grained control over data restoration.
+* **Standby Recovery**: PgBackRest can directly restore a PostgreSQL standby, streamlining the recovery process and reducing the need for manual intervention.
+
+#### Installation
+
+PgBackRest is provided as a package for most Linux distributions, and it is available on macOS via Homebrew, and its source code is also available on GitHub. For detailed installation instructions, consult the official [install guide](https://pgbackrest.org/user-guide.html#install).
+
+#### Configuration
+
+To configure PgBackRest, you'll need to create a [`pgbackrest.conf`](https://pgbackrest.org/user-guide.html#configuration) file in the database server and, if applicable, on the server where remote backups will be taken. This file contains information about your PostgreSQL instance(s) and backup repository storage.
+
+Basic configuration options include:
+
+* `repo1-path`: Specifies the directory where backup files will be stored.
+* `process-max`: Defines the maximum number of processes to use for parallel operations.
+* `log-level-console` and `log-level-file`: Control the log output levels for console and log file, respectively.
+
+For a complete list of configuration options, refer to the official [configuration reference](https://pgbackrest.org/user-guide.html#configuration-reference).
+
+#### Usage
+
+Performing backups and restores with PgBackRest involves executing commands such as `backup`, `restore`, and `archive-push`. The options for these commands are usually defined in the configuration file, allowing for straightforward execution.
+
+Here are some basic examples:
+
+* To create a full backup:
+
+  ```
+  pgbackrest backup
+  ```
+
+* To create an incremental backup:
+
+  ```
+  pgbackrest backup --type=incr
+  ```
+
+* To restore a backup:
+
+  ```
+  pgbackrest restore
+  ```
+
+For a comprehensive list of commands and their options, consult the official [command reference](https://pgbackrest.org/user-guide.html#command-reference).
+
+In conclusion, PgBackRest is a powerful and efficient backup management tool for PostgreSQL databases that offers advanced features such as parallel compression, incremental backups, and PITR. By incorporating PgBackRest into your PostgreSQL DBA toolkit, you'll ensure your data is well protected and recoverable when needed.

src/data/roadmaps/postgresql-dba/content/107-postgresql-infrastructure-skills/102-backup-recovery-tools/103-pg-probackup.md

@@ -1 +1,54 @@
-# Pg probackup
+# pg_probackup
+
+## pg_probackup
+
+`pg_probackup` is an advanced backup and recovery tool designed to work with PostgreSQL databases. This open-source utility provides efficient, reliable, and flexible backup solutions for PostgreSQL administrators, allowing them to create full, incremental, and differential backups, perform point-in-time recovery, and manage multiple backup instances.
+
+### Features
+
+Some of the key features of `pg_probackup` include:
+
+1. **Backup Types**: Supports full, page-level incremental, and ptrack (block-level incremental) backups.
+2. **Backup Validation**: Ensures the consistency and correctness of the backups with built-in validation mechanisms.
+3. **Backup Compression**: Allows you to save storage space by compressing backup files.
+4. **Multi-threading**: Speeds up the backup and recovery process by taking advantage of multiple CPU cores.
+5. **Backup Retention**: Automatically deletes old backup files based on a retention policy.
+6. **Backup Management**: Manages multiple backup instances and performs various backup maintenance tasks.
+7. **Point-in-Time Recovery**: Allows you to recover the database to a specific point in time, based on transaction log (WAL) files.
+8. **Standby Support**: Allows you to perform backups from a standby database server.
+9. **Tablespaces**: Supports backing up and restoring PostgreSQL tablespaces.
+10. **Remote Mode**: Allows you to perform backup and recovery tasks on a remote PostgreSQL server.
+
+### Installation
+
+To install `pg_probackup`, follow the steps outlined in the official documentation: [https://github.com/postgrespro/pg_probackup#installation](https://github.com/postgrespro/pg_probackup#installation)
+
+### Basic Usage
+
+Here's a brief overview of the basic commands used with `pg_probackup`:
+
+- To create a backup:
+
+```
+pg_probackup backup -B /path/to/backup/catalog -D /path/to/datadir --instance your_instance_name --backup-mode=full --remote-proto=protocol --remote-host=host_address --remote-user=user_name
+```
+
+- To restore a backup:
+
+```
+pg_probackup restore -B /path/to/backup/catalog -D /path/to/new/datadir --instance your_instance_name --recovery-target-time="YYYY-MM-DD HH:MI:SS"
+```
+
+- To validate a backup:
+
+```
+pg_probackup validate -B /path/to/backup/catalog --instance your_instance_name
+```
+
+- To manage backup retention:
+
+```
+pg_probackup delete -B /path/to/backup/catalog --instance your_instance_name --delete-expired --retention-redundancy=number_of_backups --retention-window=days
+```
+
+For more details and advanced usage, consult the official documentation: [https://postgrespro.com/docs/postgresql-14/pg-probackup](https://postgrespro.com/docs/postgresql-14/pg-probackup)

src/data/roadmaps/postgresql-dba/content/107-postgresql-infrastructure-skills/102-backup-recovery-tools/104-pg-dump.md

@@ -1 +1,60 @@
-# Pg dump
+# pg_dump
+
+## pg_dump: A Brief Summary
+
+`pg_dump` is a backup recovery tool specifically designed for PostgreSQL databases. This utility allows you to create a logical backup of your entire database, individual tables, or specific objects within a database. Logical backups represent the structure (schema) and data stored inside your database in the form of SQL statements. With `pg_dump`, you can easily create a backup file to store your data and restore it whenever needed.
+
+### Benefits of using pg_dump
+
+- **Portability**: `pg_dump` produces a text or binary formatted output that can be used to restore your database on different platforms and PostgreSQL versions.
+- **Object-Level Backup**: You have the flexibility to selectively backup specific objects, like individual tables or functions, from your database.
+- **Consistency**: Even when working with a running database, it ensures a consistent snapshot of your data by using internal database mechanisms like transactions and locks.
+
+### How to use pg_dump
+
+Here's a basic syntax for using `pg_dump`:
+
+```
+pg_dump [options] target_database
+```
+
+Some important options include:
+
+- `-f, --file`: Specifies the output file name for the backup.
+- `-F, --format`: Defines the output format, either plain-text SQL script (`p`), custom format (`c`) or tarball format (`t`).
+- `-U, --username`: Sets the database user name to connect as.
+- `-W, --password`: Forces a password prompt.
+- `-t, --table`: Backs up only the specified table(s).
+- `--data-only`: Dumps data without schema (table structures, indexes, etc.)
+- `--schema-only`: Dumps schema without the actual data.
+
+Here's an example of creating a backup of an entire database:
+
+```
+pg_dump -U my_user -W -F t -f my_backup.tar my_database
+```
+
+### Restoring backups using pg_restore
+
+For backups created in custom format (`c`) or tarball format (`t`), PostgreSQL provides a separate tool, `pg_restore`, to restore the backup. Here's a basic syntax for using `pg_restore`:
+
+```
+pg_restore [options] backup_file
+```
+
+Some important options include:
+
+- `-d, --dbname`: Specifies the target database to restore into.
+- `-U, --username`: Sets the database user name to connect as.
+- `-W, --password`: Forces a password prompt.
+- `-C, --create`: Creates a new database, dropping any existing database with the same name.
+- `--data-only`: Restores data without schema (table structures, indexes, etc.)
+- `--schema-only`: Restores schema without the actual data.
+
+Example of restoring a backup:
+
+```
+pg_restore -U my_user -W -d my_database my_backup.tar
+```
+
+In summary, `pg_dump` and `pg_restore` are powerful and flexible tools that you can use to manage your PostgreSQL database backups and recoveries, ensuring data safety and recoverability in various disaster scenarios.

src/data/roadmaps/postgresql-dba/content/107-postgresql-infrastructure-skills/102-backup-recovery-tools/105-pg-dumpall.md

@@ -1 +1,41 @@
-# Pg dumpall
+# pg_dumpall
+
+### pg_dumpall
+
+`pg_dumpall` is a utility tool in PostgreSQL that allows you to create a backup of all the databases in a PostgreSQL server. It is especially useful for DBAs who need a complete backup of the entire PostgreSQL system, including global objects such as roles, tablespaces, and databases. 
+
+#### Usage
+
+To use `pg_dumpall`, simply execute the command in the following format:
+
+```
+pg_dumpall [OPTIONS] > outputfile
+```
+
+The PostgreSQL server's entire contents will be written to the specified `outputfile`. Some commonly used options with `pg_dumpall` include:
+
+- `-h`: Specifies the server host. If not provided, it will default to the environment variable `PGHOST`, or "local socket" if none is set.
+- `-p`: Specifies the server port number. If not provided, it will default to the environment variable `PGPORT`, or 5432 if none is set.
+- `-U`: Sets the PostgreSQL username. If not provided, it will default to the environment variable `PGUSER`, or the username of the system it is being executed on, if none is set.
+- `-W`: Prompts for a password. By default, a password is not required.
+- `-f`: Specifies the output file. If not provided, it will default to the standard output.
+- `--globals-only`: Dumps only global objects (roles, tablespaces).
+- `--roles-only`: Dumps only role information.
+- `--tablespaces-only`: Dumps only tablespace information.
+
+#### Restoring a Backup
+
+Restoring a backup created using `pg_dumpall` is easy. Simply execute the below command:
+
+```
+psql -f outputfile postgres
+```
+
+This command reads the SQL commands in the `outputfile` and executes them on the PostgreSQL server. Replace "outputfile" with the file created during the backup process.
+
+#### Notes 
+
+- `pg_dumpall` doesn't support parallel processing, so for large databases, it might take a considerable amount of time to create a backup.
+- Consider using the `--clean` option to include drop statements in the SQL script, which is useful when restoring a backup to an existing system, as it will remove existing objects before recreating them.
+
+In conclusion, `pg_dumpall` is a powerful and essential tool for PostgreSQL DBAs that provides an easy, comprehensive solution for creating full backups of the entire PostgreSQL server system.

src/data/roadmaps/postgresql-dba/content/107-postgresql-infrastructure-skills/102-backup-recovery-tools/106-pg-restore.md

@@ -1 +1,48 @@
-# Pg restore
+# pg_restore
+
+### Pg_restore
+
+`Pg_restore` is a powerful and essential utility provided by PostgreSQL for recovering your database from a previously created dump file. It can be used to restore an entire database or individual database objects, such as tables, indexes, and sequences.
+
+#### Key Features
+
+- Restores data from custom, tar, and directory format archival outputs.
+- Allows selective restoration of specific database objects.
+- Supports parallel restoration of large databases.
+- Displays a preview of the restoration process with the `-L` option.
+
+#### Usage
+
+The basic syntax to use `pg_restore` is given below:
+
+```
+pg_restore [options] [file-name]
+```
+
+Here, `options` represent different configuration flags, and `file-name` is the name of the backup file created using `pg_dump`.
+
+##### Example
+
+To restore a database named `mydatabase` from a tar file named `mydatabase.tar`, you can use the following command:
+
+```
+pg_restore -U postgres -C -d mydatabase -v -Ft mydatabase.tar
+```
+
+In this example:
+
+- `-U` specifies the username for the PostgreSQL server (in this case, `postgres`).
+- `-C` creates the database before restoring.
+- `-d` selects the target database.
+- `-v` displays verbose output as the restoration progresses.
+- `-Ft` specifies that the backup format is tar.
+
+#### Important Notes
+
+- Note that `pg_dump` and `pg_restore` must be used together as they are designed to complement each other for creating and restoring backup files. Using other tools or processes for restoration may lead to unreliable results.
+
+- Please be aware of PostgreSQL version compatibility between the server where the dump was created and the target server being restored.
+
+- It is recommended to practice using `pg_restore` in a test environment before applying them to your production systems.
+
+In conclusion, `pg_restore` is a powerful yet easy-to-use PostgreSQL utility designed to simplify the process of restoring your databases. Getting familiar with `pg_restore` and its options will help you be more confident in managing and maintaining the integrity of your data.

src/data/roadmaps/postgresql-dba/content/107-postgresql-infrastructure-skills/102-backup-recovery-tools/107-pg-basebackup.md

@@ -1 +1,55 @@
-# Pg basebackup
+# pg_basebackup
+
+# Pg_basebackup
+
+`pg_basebackup` is a utility that allows you to take a base backup of your PostgreSQL database cluster. It is a standalone tool that can create a consistent snapshot of the entire PostgreSQL database file system. The output of the command is a binary copy of the directories and files which are required to start a standalone PostgreSQL instance.
+
+## Features
+
+* Generates a full backup of the database cluster
+* Supports compression for the backup output
+* Allows connection to the database server using a replication connection
+* Supports parallelizing and streaming the backups
+* Ability to include or exclude specific tablespaces in the backup
+* Offers support for various backup output formats such as tar, directory, and plain
+
+## Usage
+
+```
+pg_basebackup [OPTIONS]...
+```
+
+### Common Options
+
+* `-D`, `--pgdata=DIR` : Specifies the directory where the output will be saved.
+* `-F`, `--format=FORMAT` : Specifies the output format. Possible values are `tar`, `plain`, and `directory`. The default is `plain`.
+* `-X`, `--xlog-method=FETCH|MULTIPLEX` : Selects the method to fetch Write-Ahead Logs (WAL). `FETCH` (default) fetches the log together with the final checkpoint, while `MULTIPLEX` allows parallel backup and WAL streaming.
+* `-P`, `--progress` : Shows progress information during the backup.
+* `-z`, `--gzip` : Compresses the tar output with gzip.
+* `-Z`, `--compress=VALUE` : Compresses the tar output with gzip at the specified compression level (0 - 9).
+
+## Examples
+
+1. Taking a full base backup of the database cluster:
+
+```bash
+pg_basebackup -D /path/to/output
+```
+
+2. Taking a base backup in tar format with gzip compression:
+
+```bash
+pg_basebackup -D /path/to/output -F tar -z
+```
+
+3. Taking a base backup in directory format with progress information:
+
+```bash
+pg_basebackup -D /path/to/output -F directory -P
+```
+
+## Considerations
+
+Remember that taking a base backup could result in a substantial amount of disk space and I/O activity. It is essential to plan and schedule these backups during periods of reduced database activity if possible. Furthermore, plan for disk space requirements when generating backups, especially when using compression options.
+
+`pg_basebackup` serves as an excellent starting point for implementing backup and recovery strategies in PostgreSQL, as it provides a consistent snapshot of the database cluster. However, it is crucial to complement base backups with regular WAL archiving and additional recovery techniques to ensure optimal database protection.

src/data/roadmaps/postgresql-dba/content/107-postgresql-infrastructure-skills/102-backup-recovery-tools/108-backup-validation-procedures.md

@@ -1 +1,64 @@
-# Backup validation procedures
+# Backup Validation Procedures
+
+# Backup Validation Procedures
+
+Backup validation is a critical aspect of PostgreSQL DBA tasks. It is essential to ensure that your backups are valid, restorable, and contain all the required data. In this section, we will explore various aspects of backup validation procedures.
+
+## Importance of Backup Validation
+
+Backup validation is essential for several reasons:
+
+1. **Peace of Mind**: Ensuring that the backups are verified gives you the confidence that they can be restored when needed.
+2. **Data Integrity**: Ensuring that your data within the backup is consistent and not corrupted.
+3. **Compliance**: Depending on your industry, there might be regulatory requirements for validating backups regularly.
+
+## Validation Techniques
+
+There are various techniques to validate backups. Some of the popular ones are:
+
+### 1. Perform a Test Restore
+
+The most reliable way to validate a backup is to restore it to another instance/integration environment and verify the restored data. Here are some steps you should follow:
+
+1. Perform a full restore from your latest backup
+2. Check the logs to ensure there were no errors during the restore process
+3. Compare the restored data against the original database/data sources to ensure data integrity
+
+### 2. Use pg_checksums Tool
+
+PostgreSQL-12 onwards, the `pg_checksums` tool can be used to enable, disable, and verify checksums in a database cluster. It can be used to validate the backup data:
+
+1. Scan the backup directory
+2. Calculate the checksums for data blocks
+3. Compare them against the original cluster's checksums
+4. Report any inconsistencies found
+
+Run the following command to verify the checksums of a data directory:
+
+```bash
+pg_checksums -D /path/to/backup/directory
+```
+
+### 3. Leverage pgBackRest/--test Flag
+
+If you are using `pgBackRest`, there's a built-in validation mechanism using the `--test` flag. Running the following command will validate the latest backup without actually restoring it:
+
+```bash
+pgbackrest --stanza=mydb --test
+```
+
+### 4. Query pg_statistic Tables
+
+PostgreSQL periodically runs the `ANALYZE` command to gather statistics on tables. After restoring a backup, querying the `pg_statistic` system catalog tables can give insights about the restored data.
+
+## Backup Validation Frequency
+
+It is essential to find the right balance between the effort to validate backups and the reassurance of data safety. Validation can be performed:
+
+1. Every time a full or differential backup is created
+2. Periodically, such as weekly or monthly
+3. After significant database changes, like a schema upgrade or a major data import
+
+It's up to the DBA to determine the appropriate level of validation and frequency based on their requirements and limitations.
+
+In conclusion, backup validation is a vital step in maintaining a high level of data protection in your PostgreSQL environment. Regularly following validation procedures as part of your DBA activities will ensure that your backups are reliable and that data recovery is possible when required.

src/data/roadmaps/postgresql-dba/content/107-postgresql-infrastructure-skills/102-backup-recovery-tools/index.md

@@ -1 +1,27 @@
-# Backup recovery tools
+# Backup / Recovery Tools
+
+### Backup Recovery Tools
+
+As a PostgreSQL database administrator, having a good understanding of backup recovery tools is essential for ensuring the availability and integrity of your databases. In this section, we will discuss the key backup recovery tools every PostgreSQL DBA should be familiar with.
+
+#### 1. pg_dump
+
+`pg_dump` is the most famous tool for creating a database backup in PostgreSQL. It can generate SQL scripts to create the database schema (tables, indexes, etc.), as well as data for a specific database. The generated script can be executed on the same or another PostgreSQL database server to recreate the database. This makes it a useful tool for making a logical backup of your database, migrating your database to another server, or cloning it for development/testing purposes.
+
+#### 2. pg_dumpall
+
+While `pg_dump` is designed for backing up individual databases, `pg_dumpall` can back up all databases, tablespaces, roles, and other necessary information from a PostgreSQL server. This makes it suitable for full cluster-level backups. However, it only ensures logical backups, not physical backups.
+
+#### 3. pg_basebackup
+
+`pg_basebackup` is a command-line tool for creating a physical backup of a PostgreSQL database cluster. It generates a complete directory structure that can be used to restore the entire database cluster. The resulting backup includes all the necessary WAL (Write Ahead Log) files required to ensure consistency when restoring the database. It ensures a point-in-time consistent backup and is useful for setting up a replication environment, such as streaming replication or disaster recovery solutions.
+
+#### 4. WAL-E / WAL-G
+
+WAL-E and WAL-G are open-source tools for managing continuous archiving of PostgreSQL WAL files and base backups. They are designed for disaster recovery and provide efficient and encrypted storage of your PostgreSQL data. These tools support various storage providers like Amazon S3, Google Cloud Storage, and Azure Blob Storage, allowing seamless integration with cloud platforms. WAL-G is an enhanced version of WAL-E with better performance, compression, and additional features.
+
+#### 5. Barman (Backup & Recovery Manager)
+
+Barman is a popular open-source tool used for managing backups and disaster recovery for PostgreSQL. It automates the process of creating and managing base backups and WAL files by providing a range of continuous archiving and point-in-time recovery options. Barman supports remote and local backup strategies and various backup retention policies. By using Barman, you can reliably protect your PostgreSQL data and recover it in case of a failure.
+
+In conclusion, as a PostgreSQL DBA, it is crucial to understand and use these backup recovery tools to ensure the safety and availability of your databases. Always remember that a well-thought-out backup and recovery strategy can save you from major disasters and data loss, so invest your time in learning these tools and implementing a robust backup plan.

src/data/roadmaps/postgresql-dba/content/107-postgresql-infrastructure-skills/103-upgrade-procedures/100-using-pg-upgrade.md

@@ -1 +1,44 @@
-# Using pg upgrade
+# Using `pg_upgrade`
+
+# Using `pg_upgrade`
+
+`pg_upgrade` is a utility that allows you to perform an in-place upgrade of your PostgreSQL database from one major version to another. This utility is highly efficient as it does not require the creation of a new cluster or the use of SQL dump and restore. It achieves this by directly modifying the system catalogues and updating the data files' pointers with the new database version.
+
+## Benefits of `pg_upgrade`
+
+- Quick and efficient upgrades without the need to dump and restore the entire database.
+- Manages upgrades spanning multiple major PostgreSQL versions.
+- Supports custom installations and different platforms.
+
+## Steps to use `pg_upgrade`
+
+1. **Install the new PostgreSQL version**: First, you need to install the new major version of PostgreSQL on your system. Make sure to leave the old version intact.
+
+2. **Stop the old PostgreSQL server**: To avoid any conflicts or data corruption, shut down the old PostgreSQL server before running the `pg_upgrade` process.
+
+3. **Create a new data directory**: Create a new empty data directory for the new PostgreSQL version. Ensure that the same user who owns the old data directory owns the new directory as well.
+
+4. **Perform the upgrade**: Run the `pg_upgrade` command to perform the upgrade. Specify the paths of the old and new data directories and executables, such as:
+   ```
+   pg_upgrade \
+       --old-datadir /path/to/old/data/dir \
+       --new-datadir /path/to/new/data/dir \
+       --old-bindir /path/to/old/bin/dir \
+       --new-bindir /path/to/new/bin/dir
+   ```
+
+5. **Check for errors**: During the upgrade process, `pg_upgrade` creates log files in the home directory. Review these logs to ensure that there were no errors during the upgrade.
+
+6. **Start the new PostgreSQL server**: Once the upgrade process is complete, start the new PostgreSQL server with the new data directory.
+
+7. **Run analyze**: As a final step, run the `ANALYZE` command on the new system, to ensure that the planner has accurate statistics.
+
+8. **Check and remove old data**: Use the new server for a while and ensure everything is working as expected before deleting the old data directory.
+
+## Rollback plan
+
+In case the upgrade process fails or you encounter issues in the new version, you can always roll back to the old version. To do this, simply stop the new PostgreSQL server and restart the old server with the old data directory in the configuration file.
+
+## Conclusion
+
+`pg_upgrade` is an essential tool for any PostgreSQL DBA, as it greatly simplifies the process of upgrading to a new major version. By following the steps outlined above, you can perform quick and efficient upgrades with minimal downtime.

src/data/roadmaps/postgresql-dba/content/107-postgresql-infrastructure-skills/103-upgrade-procedures/101-using-logical-replication.md

@@ -1 +1,50 @@
-# Using logical replication
+# Using Logical Replication
+
+## Using Logical Replication for PostgreSQL Upgrade Procedure
+
+Logical replication is a compelling method to upgrade PostgreSQL instances with minimal downtime. It allows the transfer of data changes between two different database versions, enabling smoother upgrades without sacrificing database availability.
+
+### Benefits of using Logical Replication
+
+- **Minimal downtime**: Logical replication minimizes downtime during the upgrade process, ensuring your applications experience less disruption.
+- **Version compatibility**: You can replicate between different PostgreSQL versions, making it ideal for upgrading to a new release.
+- **Selective data replication**: You have the flexibility to replicate specific tables, schemas, or databases instead of the entire cluster.
+
+### Steps for upgrading with Logical Replication
+
+1. **Prepare your new PostgreSQL instance**: Set up a new PostgreSQL instance that will serve as the upgraded version. This new instance can run on a separate server, virtual machine, or container.
+
+2. **Enable logical replication**: Enable logical replication on both the old and new PostgreSQL instances by setting up the required configuration options in `postgresql.conf`:
+    ```
+    wal_level = logical
+    max_replication_slots = 4
+    max_wal_senders = 4
+    ```
+    Don't forget to set appropriate authentication rules for replication connections in `pg_hba.conf` as well.
+
+3. **Create a publication on the old instance**: A publication defines the set of tables that need to be replicated. You can create a publication for specific tables, schema, or the entire database depending on your requirements. Example:
+    ```
+    CREATE PUBLICATION my_publication FOR ALL TABLES;
+    ```
+
+4. **Create a subscription on the new instance**: A subscription receives data changes from a publication. On the new PostgreSQL instance, create a subscription to the publication from the old instance. Example:
+    ```
+    CREATE SUBSCRIPTION my_subscription
+    CONNECTION 'host=old_instance_host port=5432 user=replication_user password=replication_password dbname=my_database'
+    PUBLICATION my_publication;
+    ```
+
+5. **Monitor the replication progress**: Check the replication status to ensure all changes are being synchronized between the old and new instances using the following query:
+    ```
+    SELECT * FROM pg_stat_subscription;
+    ```
+
+6. **Switchover to the new instance**: Once the replication catches up and the new instance is in sync, perform a brief switchover by stopping writes to the old instance, ensuring the new instance is fully caught up, and then redirecting clients to the new instance.
+
+7. **Drop the subscription and change publication**: After the upgrade is completed and traffic is going to the new instance, you can remove the subscription on the new instance and change the publication on the old instance to clean up. Example:
+    ```
+    DROP SUBSCRIPTION my_subscription;
+    DROP PUBLICATION my_publication;
+    ```
+
+Logical replication is an efficient method to upgrade PostgreSQL instances with minimal downtime and version compatibility. By following the steps outlined above, you can ensure a smooth upgrade experience without disrupting database availability.

src/data/roadmaps/postgresql-dba/content/107-postgresql-infrastructure-skills/103-upgrade-procedures/index.md

@@ -1 +1,44 @@
-# Upgrade procedures
+# Upgrade Procedures
+
+## Upgrade Procedures
+
+As a PostgreSQL DBA, one of the essential tasks is to perform database system upgrades. Upgrades are necessary to obtain new features, security patches, and bug fixes. There are two main techniques to upgrade a PostgreSQL instance: 
+
+1. **In-Place Upgrade**: It involves upgrading the PostgreSQL software without changing the data directory. This process is also known as minor version upgrade.
+2. **Logical Upgrade**: It involves using tools like `pg_dump` and `pg_upgrade` to create a new cluster with the newer version and then migrate the data to the new cluster. This process is also known as major version upgrade.
+
+### In-Place Upgrade
+
+An in-place upgrade is used for minor version upgrades (e.g., 12.4 to 12.5), which involve only updates to the PostgreSQL software itself without any changes to the data format or the server features.
+
+Here are the general steps for an in-place upgrade:
+
+1. Verify that the new minor version of PostgreSQL is compatible with your database and applications.
+2. Backup your database as a precaution.
+3. Download and install the new minor version of PostgreSQL.
+4. Restart the PostgreSQL service to start using the new version.
+
+### Logical Upgrade
+
+A logical upgrade is required when upgrading to a new major version of PostgreSQL (e.g., 11.x to 12.x), which may introduce changes to the data format or the server features.
+
+Here are the general steps for a logical upgrade:
+
+1. Verify that the new major version is compatible with your database and applications.
+2. Backup your database.
+3. Install the new major version of PostgreSQL in parallel with the existing version.
+4. Stop the old PostgreSQL service.
+5. Use `pg_upgrade` to perform the upgrade:
+    1. Create a new data directory for the new version.
+    2. Run `pg_upgrade` to migrate the data from the old data directory to the new data directory.
+6. Verify the upgrade process by testing your applications and checking the logs.
+7. Switch your applications to the new PostgreSQL service.
+8. Once everything is verified, remove the old PostgreSQL instance and the old data directory.
+
+### Additional Considerations
+
+- Always read the release notes of the new version to understand the changes, new features, and any incompatibilities.
+- Perform thorough testing before upgrading production environments.
+- Monitor the PostgreSQL instance after the upgrade to ensure stability and performance.
+
+By understanding these upgrade procedures, you are well-equipped to keep your PostgreSQL infrastructure secure, up-to-date, and optimized for your applications.

src/data/roadmaps/postgresql-dba/content/107-postgresql-infrastructure-skills/104-cluster-management/100-patroni.md

@@ -1 +1,45 @@
-# Patroni
+# Patroni
+
+## Patroni
+
+[Patroni](https://github.com/zalando/patroni) is a modern, open-source, and highly-available PostgreSQL database cluster management tool. It ensures that the master automatically fails over to a standby in case of any issues, and plays a vital role in keeping the PostgreSQL database highly available.
+
+### Overview
+
+When running a PostgreSQL database cluster, it is essential to provide automated failover and recovery mechanisms to prevent downtimes and data loss. Patroni acts as an effective solution by enabling automated failover, which promotes a healthy replica to become the new master in case the current master node fails.
+
+### Key Features of Patroni
+
+* **High Availability:** Patroni uses consensus-based algorithms like [Raft](https://raft.github.io/) or [ZooKeeper](https://zookeeper.apache.org/) to maintain a distributed and highly-available PostgreSQL cluster.
+* **Automatic Failover:** Patroni handles master failure scenarios by monitoring and switching to the most appropriate replica.
+* **Switchover and Planned Maintenance:** It provides functionality to perform controlled switchover to a replica node for maintenance or other reasons.
+* **Configuration Management:** Patroni takes care of configuration files (e.g., `postgresql.conf`) and automatically synchronizes them across the cluster.
+* **Replica management:** It supports various replication methods, including streaming replication, logical replication, and synchronous replication.
+* **Monitoring and Health Checks:** Patroni provides REST APIs for monitoring the PostgreSQL cluster health and various performance metrics.
+* **Integration:** It can be easily integrated with various configuration stores (e.g., ZooKeeper, etcd, Consul) and load balancers like HAProxy.
+
+### Setting up Patroni
+
+Before setting up Patroni, you need to have at least two PostgreSQL servers and a configuration store (ZooKeeper, etcd, or Consul). Follow these steps to set up a highly-available PostgreSQL cluster using Patroni:
+
+1. **Install Patroni:** Patroni can be installed using pip:
+
+   ```
+   pip install patroni
+   ```
+   
+2. **Configure Patroni:** Create a `patroni.yml` configuration file in the PostgreSQL server. This file contains settings like PostgreSQL connections, configuration store location, and replication settings.
+
+3. **Start Patroni:** Run the following command on each of your PostgreSQL servers:
+
+   ```
+   patroni /path/to/patroni.yml
+   ```
+   
+4. **Verify Cluster State:** Use Patroni's REST API or CLI tool to verify the cluster state and health.
+
+With Patroni up and running, you can perform various cluster management tasks like failover, switchover, and monitoring.
+
+### Conclusion
+
+Patroni is a highly-effective PostgreSQL DBA tool to manage and maintain highly-available database clusters. By incorporating automated failovers, effective replica management, and easy configuration, you can ensure your PostgreSQL database remains reliable and available at all times.

src/data/roadmaps/postgresql-dba/content/107-postgresql-infrastructure-skills/104-cluster-management/101-patroni-alternatives.md

@@ -1 +1,43 @@
-# Patroni alternatives
+# Patroni Alternatives
+
+# Patroni Alternatives
+
+While Patroni is a widely used and popular tool for managing PostgreSQL high availability clustering, there are other alternatives that can be considered for managing your PostgreSQL clusters. In this section, we will explore some common alternatives to Patroni, their advantages, and drawbacks.
+
+## 1. Repmgr
+
+[Repmgr](https://repmgr.org/) is another popular open-source tool for managing replication and failover within a group of PostgreSQL servers. It is developed and maintained by 2ndQuadrant, known for their expertise in database administration. Some key features of Repmgr are:
+
+- Automated failover management
+- Switchover operation support
+- Creation of replication clusters
+- Command-line interface to manage PostgreSQL clusters
+
+Repmgr is convenient to use but does not come with a built-in consensus mechanism like Patroni, which uses the [Raft Consensus Algorithm](https://raft.github.io/).
+
+## 2. Stolon
+
+[Stolon](https://github.com/sorintlab/stolon) is a cloud-native PostgreSQL high availability manager developed by SorintLab. It provides an almost similar feature set to Patroni, with some improvements:
+
+- Cloud-native solution, developed with Kubernetes in mind
+- Flexible architecture
+- Built-in proxy that reroutes connections to the current primary node
+
+While Stolon provides a high level of flexibility and Kubernetes integration, its downside is the increased complexity compared to other managers, which can be challenging to set up and manage properly.
+
+## 3. Pgpool-II
+
+[Pgpool-II](https://www.pgpool.net/mediawiki/index.php/Main_Page) is another popular PostgreSQL clustering tool that offers high availability, load balancing, and connection pooling features. Key benefits of Pgpool-II include:
+
+- Load balancing to distribute queries to multiple servers
+- Connection pooling to reduce the overhead of opening new connections
+- Watchdog for automated failover operations
+- In-memory caching
+
+Pgpool-II has a different focus compared to Patroni or Repmgr, as it focuses on load balancing and connection pooling. While it offers similar high availability management features, it is mainly designed for handling large-scale PostgreSQL environments.
+
+## Summary
+
+Each PostgreSQL clustering solution has its advantages and drawbacks. Patroni offers a user-friendly and powerful solution with advanced features like built-in consensus algorithms. Repmgr is a convenient option for managing PostgreSQL replication and failover. Stolon offers a cloud-native solution for those who mainly work with Kubernetes. Finally, Pgpool-II is an excellent choice for large-scale PostgreSQL environments in need of load balancing and connection pooling.
+
+As a PostgreSQL DBA, you should carefully evaluate and compare these alternatives to find the best fit for your specific use case and requirements.

src/data/roadmaps/postgresql-dba/content/107-postgresql-infrastructure-skills/104-cluster-management/index.md

@@ -1 +1,32 @@
-# Cluster management
+# Cluster Management
+
+## Cluster Management
+
+Cluster management involves overseeing and administering the operations of a group of PostgreSQL servers that collectively form a cluster. In this section, we'll discuss the key aspects of cluster management, including the techniques and tools needed to effectively manage a PostgreSQL cluster.
+
+### Overview
+
+A PostgreSQL cluster is a collection of database servers that work together to provide high availability, fault tolerance, and scalability. The key aspects of PostgreSQL cluster management include:
+
+- Configuring and deploying the cluster
+- Monitoring the performance of the cluster
+- Ensuring high availability and fault tolerance
+- Scaling the cluster in response to changing workloads
+
+### Configuring and Deploying the Cluster
+
+As a PostgreSQL DBA, you'll need to handle setting up the configuration of your PostgreSQL cluster. This process involves defining the architecture of the cluster, selecting the appropriate hardware, and configuring the software. You may also need to set up replication between the nodes in the cluster, for example, by using streaming replication or logical replication.
+
+### Monitoring the Performance of the Cluster
+
+Ongoing monitoring is crucial in order to assess the health and performance of the PostgreSQL cluster. You should set up monitoring tools and processes that can analyze the performance of the cluster and alert you to any issues that may arise, such as slow queries or hardware failures. Some useful tools for monitoring PostgreSQL clusters include [pg_stat_statements](https://www.postgresql.org/docs/current/pgstatstatements.html), [pg_stat_activity](https://www.postgresql.org/docs/current/monitoring-stats.html#PG-STAT-ACTIVITY-VIEW), and [PgBouncer](https://www.pgbouncer.org/).
+
+### Ensuring High Availability and Fault Tolerance
+
+One of the main goals of a PostgreSQL cluster is to provide high availability and fault tolerance. This means that the cluster must be resilient to outages, component failures, and network disruptions. You'll need to implement techniques such as load balancing, automatic failover, and data replication to ensure that your cluster remains fully operational even in the event of a failure.
+
+### Scaling the Cluster
+
+As a PostgreSQL DBA, you'll also need to manage the growth of your cluster as your application's requirements change over time. This may involve adding or removing nodes from the cluster, or modifying the hardware and configuration of existing nodes. Scaling the PostgreSQL cluster can be done using methods like partitioning, sharding, or read replicas to distribute the workload among multiple nodes.
+
+In conclusion, PostgreSQL cluster management involves several crucial tasks aimed at ensuring the efficient operation, high availability, fault tolerance, and scalability of your PostgreSQL database infrastructure. By mastering these skills, you'll be well-equipped to manage a PostgreSQL cluster and address the various challenges that may arise in your role as a PostgreSQL DBA.

src/data/roadmaps/postgresql-dba/content/107-postgresql-infrastructure-skills/105-kubernetes-deployment/100-simple-stateful-setup.md

@@ -1 +1,35 @@
-# Simple stateful setup
+# Simple Stateful Setup
+
+## Simple Stateful Setup
+
+In this section, we will discuss a simple stateful setup for PostgreSQL in a Kubernetes environment. The main goal of this setup is to provide a resilient and highly available PostgreSQL deployment that can be managed and scaled easily.
+
+### StatefulSets
+
+PostgreSQL is a stateful application that requires persistent storage for data durability. Kubernetes provides a built-in abstraction called `StatefulSet` that solves this problem. A `StatefulSet` manages the deployment and scaling of a set of Pods, and provide guarantees about the ordering and uniqueness of these Pods.
+
+In our simple stateful setup, we'll use a single-replica `StatefulSet` to manage a single PostgreSQL instance. This will provide a basic level of fault tolerance, as a new Pod will be automatically created if the current instance fails.
+
+### PersistentVolume and PersistentVolumeClaim
+
+To ensure data persistence during Pod restarts, we will use Kubernetes `PersistentVolume` (PV) and `PersistentVolumeClaim` (PVC). A `PV` is a piece of storage in the cluster, while a `PVC` is a request for storage by a user. In our setup, we will create a PVC template, associated with the `StatefulSet`, that dynamically provisions a PV for each Pod.
+
+### ConfigMaps and Secrets
+
+ConfigMaps and Secrets are used for managing configuration data in Kubernetes. We will use a `ConfigMap` to store PostgreSQL configuration files (e.g., `postgresql.conf` and `pg_hba.conf`) and a `Secret` to store sensitive information (e.g., PostgreSQL user and password).
+
+### Load Balancer and Services
+
+To expose our PostgreSQL instance to other services, we will use a Kubernetes `Service` with the type `LoadBalancer`. This service will route external traffic to the appropriate Pod, providing a stable IP address and DNS name.
+
+### Summary
+
+Our simple stateful setup for PostgreSQL in Kubernetes includes the following components:
+
+- A single-replica StatefulSet to manage the PostgreSQL instance.
+- A PVC template to dynamically provision a PV for each Pod.
+- A ConfigMap to store PostgreSQL configuration files.
+- A Secret to store sensitive information.
+- A LoadBalancer Service to expose the PostgreSQL instance.
+
+By using these components effectively, we can create a resilient, scalable, and easy-to-manage PostgreSQL deployment in Kubernetes.

src/data/roadmaps/postgresql-dba/content/107-postgresql-infrastructure-skills/105-kubernetes-deployment/101-helm.md

@@ -1 +1,55 @@
-# Helm
+# Helm
+
+## Helm
+
+Helm is a package manager for Kubernetes that simplifies the process of deploying and managing applications on a Kubernetes cluster. Helm uses a packaging format called _charts_, which are collections of files that describe the necessary resources and configurations for running an application or service inside a Kubernetes cluster.
+
+### Key Components of Helm
+
+* **Charts**: Helm packages are called charts. A chart is a group of files that define a complete application stack, including Kubernetes objects such as deployments, services, and configuration files.
+* **Releases**: An instance of a chart running on your Kubernetes cluster is called a release. Helm allows you to roll back to a previous release, making it easy to test and troubleshoot changes without affecting production systems. It also handles versioning of your deployments.
+* **Repositories**: Helm manages your charts through repositories, which are storage locations for your chart packages. You can create your own repositories or use existing ones, such as the public Helm charts repository.
+
+### Installing Helm
+To get started with Helm, you first need to install the helm CLI on your machine. You can follow the [official guide](https://helm.sh/docs/intro/install/) to choose the installation method that suits your operating system.
+
+Once you have Helm installed, you need to set up your Kubernetes context and Tiller, the server-side component of Helm:
+
+```bash
+# Initialize helm and install Tiller
+helm init
+```
+
+### Using Helm
+After setting up Helm, you can use it to deploy applications in your Kubernetes cluster. Here is the basic workflow for using Helm:
+
+1. Search for a chart in the public repository or another repository you have access to:
+
+   ```bash
+   helm search <chart_name>
+   ```
+   
+2. Install a chart from a repository to create a release in your Kubernetes cluster:
+
+   ```bash
+   helm install <repo>/<chart_name>
+   ```
+
+3. List and manage the releases on your cluster:
+
+   ```bash
+   # List all releases
+   helm ls
+   
+   # Roll back to a previous release
+   helm rollback <release_name> <version>
+   
+   # Uninstall a release
+   helm uninstall <release_name>
+   ```
+
+4. You can also create your own charts for your applications or services. Follow the [official guide](https://helm.sh/docs/chart_template_guide/) to create your first chart.
+
+Helm greatly simplifies Kubernetes deployment processes and is a critical tool in a PostgreSQL DBA's toolbox to effectively manage and deploy PostgreSQL instances on Kubernetes.
+
+For more detailed information and advanced usage, please consult the [official Helm documentation](https://helm.sh/docs/).

src/data/roadmaps/postgresql-dba/content/107-postgresql-infrastructure-skills/105-kubernetes-deployment/102-operators.md

@@ -1 +1,38 @@
-# Operators
+# Operators
+
+## Operators in Kubernetes
+
+Operators are a method of how to extend the Kubernetes API and manage custom resources, which are specific to the application they manage. They build upon and fully utilize Kubernetes concepts, like `CustomResourceDefinition` (CRD) and `Controller`. Operators are mainly designed to handle application-specific operational tasks, with a focus on automation and scaling, to enable smoother work with Kubernetes perspectives.
+
+In the context of PostgreSQL, operators can manage the deployment, configuration, backups, and failover mechanisms for your PostgreSQL cluster.
+
+### How do Operators work?
+
+Kubernetes Operators work in a loop:
+
+1. Watch for changes in the custom resources
+2. Analyze the current state and desired state
+3. Perform necessary actions to reach the desired state
+
+This control loop helps to maintain the state of resources all the time, providing the benefits of:
+   - Built-in best practices and automation for complex stateful applications
+   - Reduce human interventions, repetitive work and chances of error
+   - Auto-scaling and self-healing in case of failures
+
+### PostgreSQL Operators
+
+There are various PostgreSQL Operators available, each having their respective advantages and trade-offs. Some popular ones include:
+
+- [Zalando's PostgreSQL Operator](https://github.com/zalando/postgres-operator): Advanced operator with highly customizable deployments, with a focus on High Availability (HA) and failover.
+- [CrunchyData's PostgreSQL Operator](https://github.com/CrunchyData/postgres-operator): Provides full application stack deployments along with disaster recovery, cloning, monitoring, and more.
+- [StackGres](https://stackgres.io/): A fully-featured operator with a focus on simplicity, providing a web UI and seamless integration with other tools.
+
+### Getting Started with Operators
+
+To work with Kubernetes and PostgreSQL operators, follow these steps:
+
+1. Choose and install the appropriate PostgreSQL Operator for your use case. Detailed guides and documentation are provided by each operator.
+2. Deploy your PostgreSQL cluster using the custom resources and configurations specific to the selected operator.
+3. Manage and monitor your PostgreSQL cluster using the operator's dedicated tools and Kubernetes-native systems.
+
+By properly utilizing PostgreSQL Operators in Kubernetes, you could create a powerful environment for managing and maintaining your PostgreSQL deployments while saving time, effort and reducing the risk of errors in manual tasks.