MySQL HeatWave combines MySQL with in-memory analytics, making it possible to process transactional and analytical workloads from the same database. This article provides a concise overview of why developers use HeatWave and the basic steps required to configure it in Oracle Cloud Infrastructure.

Why Consider MySQL HeatWave?

Running analytical and transactional queries on separate platforms often increases complexity. MySQL HeatWave reduces that overhead by bringing both workloads together in a managed cloud environment.

Some of the capabilities that make HeatWave a practical option include:

• Support for both OLTP and OLAP within the same MySQL deployment.
• In-memory query processing for faster analytical performance.
• Integrated machine learning features that work directly with MySQL data.
• Cloud-based scaling for compute and storage resources.
• Managed infrastructure that reduces administrative tasks.

Because Oracle manages much of the underlying infrastructure, teams can spend more time working with data instead of maintaining database servers.

Points to Consider Before Choosing HeatWave

Every database platform comes with trade-offs. Before adopting HeatWave, it’s useful to understand where it may not be the right fit. Some considerations include:

• It is built specifically for Oracle Cloud Infrastructure.
• Costs depend on the resources you consume.
• Support primarily focuses on MySQL environments.

For organizations already using Oracle Cloud and MySQL, these limitations may be less significant than the operational benefits.

Setting Up MySQL HeatWave

Getting started with HeatWave involves configuring the MySQL Database Service and enabling HeatWave within your Oracle Cloud account.

Begin by creating a MySQL Database Service instance if one does not already exist. During setup, choose your preferred MySQL version and assign the required compute and storage resources. After the database is available, import your existing data.

Once the data has been imported, open the Oracle Cloud Console and locate the MySQL HeatWave settings for your database. From there you can:

• Allocate memory for in-memory processing.
• Review HeatWave configuration.
• Confirm the database is ready for analytical workloads.
• Monitor performance through Oracle Cloud metrics.

After configuration, applications continue querying MySQL normally while HeatWave accelerates supported analytical operations.

FAQ

What Happens After Configuration?

Once HeatWave is enabled, everyday database operations remain familiar while analytical queries benefit from in-memory execution. Continue to:

• Run SQL queries as usual.
• Monitor database health and resource usage.
• Adjust allocated resources when workloads grow.
• Review performance metrics to optimize capacity.

Regular monitoring helps ensure the environment continues meeting performance requirements.

What Is MySQL HeatWave?

MySQL HeatWave is Oracle’s managed MySQL cloud service that combines transactional processing with in-memory analytics. It allows organizations to execute OLTP and OLAP workloads on the same data without maintaining separate analytical systems.

Is MySQL HeatWave Difficult to Set Up?

For most users, setup is relatively straightforward because Oracle manages much of the infrastructure. After creating a MySQL Database Service instance, enabling HeatWave and importing data are the primary tasks.

An Oracle Cloud account is required before deployment can begin.

Most configuration options are available directly from the Oracle Cloud Console, making the process approachable for developers and database administrators.

After deployment, ongoing administration is largely focused on monitoring and scaling resources as needed.

Conclusion

MySQL HeatWave provides a managed way to combine transactional processing with analytical workloads in a single MySQL environment. With Oracle handling much of the infrastructure, deployment is relatively simple, allowing teams to focus on their applications and data instead of database maintenance.

For a more detailed walkthrough, including the original steps and examples, read the complete guide Setting Up MySQL HeatWave: A Guided Tutorial.

How to Set Up MySQL HeatWave for Faster Analytics and Transactions was originally published in The Table — Databases and SQL on Medium, where people are continuing the conversation by highlighting and responding to this story.

Indexes play an important role in database performance, but they also require regular maintenance to remain effective. Understanding how indexes work and when they should be reviewed helps keep SQL queries efficient across open source database systems.

Why SQL Indexes Matter

Indexes make it easier for a database engine to locate rows without scanning entire tables. Much like the index of a book, they provide a quicker path to the information being requested. A well-designed indexing strategy can help by:

• Reducing the amount of data scanned.
• Improving query response times.
• Supporting efficient lookups on frequently searched columns.
• Optimizing read-heavy workloads.

Different database systems provide multiple index types, each designed for particular workloads.

Common SQL Index Types

Selecting the right index depends on how your application accesses data. Understanding the available options helps you choose an approach that matches your queries. Some commonly used index types include:

• Primary indexes for uniquely identifying rows and organizing table storage.
• B-Tree indexes for searches, sorting, and range conditions.
• Hash indexes for equality comparisons in supported storage engines.
• GIN indexes in PostgreSQL for arrays and document-style data.
• Spatial indexes for geographic objects such as points and polygons.

Each serves a different purpose, so selecting the appropriate type is just as important as creating the index itself.

Maintaining SQL Indexes

Regular maintenance helps ensure indexes continue supporting your queries instead of becoming unnecessary overhead.

Check Whether Indexes Are Used

Before making changes, verify that an index actually participates in query execution. Using the EXPLAIN statement before a SELECT query allows you to review:

• Which index was selected.
• Alternative indexes that were considered.
• Information about index length.
• The execution strategy chosen by the optimizer.

EXPLAIN
SELECT *
FROM users
WHERE email = 'user@example.com';

If an index never appears in execution plans, it may deserve further investigation.

Remove Redundant Indexes

Not every index contributes to better performance. Some increase storage requirements and slow write operations without helping query execution. When reviewing indexes:

• Compare possible_keys with the selected key.
• Review frequently executed queries.
• Adjust query structure when appropriate.
• Remove indexes that consistently remain unused.

Cleaning up unnecessary indexes can simplify maintenance while improving overall efficiency.

Review Indexes After Data Changes

Indexes change as data changes. Large numbers of:

• INSERT operations
• UPDATE operations
• DELETE operations

This can affect index efficiency over time. Periodically reviewing or rebuilding indexes helps maintain consistent performance, especially for heavily modified tables.

Keep Your Index Strategy Simple

Adding indexes everywhere is rarely beneficial. Every additional index consumes storage and increases maintenance during write operations. Before creating new indexes, consider:

• Query patterns.
• Table size.
• Read versus write activity.
• Available disk space.
• Application requirements.

A smaller collection of well-planned indexes is often easier to maintain than a large collection of overlapping ones.

Frequently Asked Questions

How do you maintain SQL indexes?

Start by selecting the appropriate index type for your workload. Review execution plans regularly, remove indexes that are no longer useful, and periodically evaluate indexes after significant data modifications. Consistent monitoring helps keep query performance stable.

Why should indexes be reviewed regularly?

Database workloads evolve over time. Queries change, tables grow, and applications develop new access patterns. Reviewing indexes ensures they continue supporting the queries that matter most instead of consuming resources unnecessarily.

When should an index be rebuilt?

Indexes may benefit from rebuilding after extensive inserts, updates, or deletes. The exact timing depends on the database platform and workload, but periodic maintenance is recommended for frequently changing data.

Why use DbVisualizer?

DbVisualizer provides tools for inspecting database objects, exploring index structures, analyzing execution plans, and working with many different database platforms through a single interface, making ongoing database maintenance more convenient.

Conclusion

Maintaining SQL indexes is an ongoing part of database administration. Reviewing execution plans, removing redundant indexes, and designing indexes around actual query patterns helps keep open source databases performing efficiently as applications grow.

For the complete guide and additional examples, read the original article Understanding SQL Index Maintenance in Open Source Databases.

SQL Index Maintenance in Open Source Databases was originally published in The Table — Databases and SQL on Medium, where people are continuing the conversation by highlighting and responding to this story.

Working with data often means moving records from one table to another. The INSERT INTO ... SELECT statement makes that possible in a single query, whether you're creating backups, migrating data, or copying filtered records.

Understanding INSERT INTO … SELECT

Instead of inserting values manually, this statement reads data from another table and writes it directly into an existing destination table. It can also work with joins and transformed values.

Before looking at an example, here are a few important things to remember:

• The destination table must already exist.
• Source and destination columns should match in order and compatible data types.
• A WHERE clause can limit which rows are copied.
• Most major SQL databases support this syntax.

The syntax is straightforward and follows the same pattern across most SQL databases.

INSERT INTO target_table (column1, column2, column3)
SELECT column1, column2, column3
FROM source_table
WHERE condition;

Example — Copy Only IT Employees

Suppose an employee table contains staff from several departments. You only want IT employees stored in a backup table with a slightly different structure.

INSERT INTO it_staff_backup (original_id, full_name, salary)
SELECT id,
       first_name || ' ' || last_name,
       salary
FROM employees
WHERE department = 'IT';

This query performs several actions at once:

• Copies employee IDs.
• Combines first and last names.
• Keeps salary information.
• Filters the results to only IT staff.

Frequently Asked Questions

Which SQL statement copies data between tables?

INSERT INTO ... SELECT copies rows from one table into another existing table without manually entering values.

Is INSERT INTO table from SELECT different?

No. Both names describe the same SQL statement. The wording changes, but the functionality stays the same.

Does Oracle support INSERT INTO … SELECT?

Yes. Oracle follows the same general syntax, allowing rows from another table or query to be inserted into an existing table.

How is it different from CREATE TABLE … SELECT?

INSERT INTO ... SELECT adds rows to an existing table. CREATE TABLE ... SELECT creates a brand-new table and fills it with query results.

Why use a visual database client?

Visual tools simplify browsing schemas, writing SQL, and exploring data while reducing manual work during database management.

Conclusion

The INSERT INTO ... SELECT statement provides a practical way to copy, filter, and reshape data using a single SQL query. It's useful whenever data needs to be transferred into an existing table without manual inserts.

Read the complete guide here INSERT INTO … SELECT Statement: What You Need to Know.

SQL INSERT INTO SELECT: Copy Data Between Tables Efficiently was originally published in The Table — Databases and SQL on Medium, where people are continuing the conversation by highlighting and responding to this story.

Working with string values is a common part of SQL development. When you need to extract everything before or after a specific character, SUBSTRING_INDEX offers a simple way to return only the part of the string you need. This article explains how the function works, where it is useful, and what to consider when using it.

Understanding SUBSTRING_INDEX

SUBSTRING_INDEX returns part of a string based on a delimiter and the number of delimiter occurrences.

Its syntax is straightforward:

SUBSTRING_INDEX(string, delimiter, count);

The function uses three parameters:

• The source string or column
• The delimiter to search for
• The occurrence count that determines where the split happens

For example:

SELECT SUBSTRING_INDEX('<https://dbvis.com>', '.', 2);

Using a negative count searches from the right side of the string:

SELECT SUBSTRING_INDEX('www.dbvis.com', '.', -2);

If any argument is NULL, the function also returns NULL.

Practical Examples

In real projects, SUBSTRING_INDEX is commonly used with table columns instead of fixed text values. It is useful for extracting structured information from larger datasets.

Common use cases include:

• Splitting IP addresses into separate parts
• Extracting email domains
• Preparing data for reporting
• Cleaning imported datasets

For example, extracting email domains is simple:

SELECT SUBSTRING_INDEX(email, '@', -1)
FROM users;

This makes it easier to group users by their email provider or perform domain-based analysis.

Performance Considerations

Using the function on large tables can become expensive because every row must be processed.

To improve efficiency, consider:

• Using indexes where appropriate
• Combining the function with aggregation
• Exporting processed results when needed
• Testing performance on larger datasets

A common reporting query looks like this:

SELECT
SUBSTRING_INDEX(email, '@', -1) AS domain,
COUNT(*) AS users
FROM users
GROUP BY domain;

Similar SQL Functions

Several database systems offer comparable functions with slightly different behavior.

Examples include:

• SUBSTRING for extracting characters by position
• RIGHT() for returning characters from the end of a string
• Pattern-based SUBSTRING in PostgreSQL

Support also varies between database systems. While MySQL and SQL Server support SUBSTRING_INDEX, Oracle, SQLite, and PostgreSQL rely on alternative string functions to achieve similar results.

Frequently Asked Questions

What is SUBSTRING_INDEX in SQL?

SUBSTRING_INDEX returns part of a string using a specified delimiter and occurrence count. It is useful when extracting values before or after a particular character.

When should I use SUBSTRING_INDEX?

Use it whenever structured text needs to be separated into smaller pieces, such as URLs, email addresses, hostnames, or IP addresses.

Which databases support SUBSTRING_INDEX?

The function is available in MySQL and SQL Server implementations. Other database systems provide alternative functions, such as SUBSTRING, SUBSTR, or pattern matching.

Conclusion

SUBSTRING_INDEX provides an efficient way to extract portions of text directly within SQL queries. Whether you're processing email addresses, IP addresses, or other structured values, understanding how the function behaves can simplify everyday database tasks.

For the complete guide, additional examples, and compatibility details, read the original article Parsing Data with SUBSTRING_INDEX: A Complete Guide.

SUBSTRING_INDEX in SQL: Extract Parts of Strings Efficiently was originally published in The Table — Databases and SQL on Medium, where people are continuing the conversation by highlighting and responding to this story.

Removing a table from a database is different from deleting its data. The SQL DROP TABLE statement permanently removes both the table definition and everything stored inside it. Understanding how it works helps you avoid accidental data loss and choose the right SQL command for each situation.

What Is SQL DROP TABLE?

A database table contains both its structure and its data. The DROP TABLE statement removes both, making the table unavailable immediately.

When executed, the database typically:

• Deletes the table definition.
• Removes every stored row.
• Deletes indexes, constraints, and triggers linked to the table.
• Releases the storage for future use.

Since this is usually a DDL operation with an implicit commit, recovering the table afterward is generally not possible.

How DROP TABLE Works

Before deleting a table, the database performs a couple of internal operations that remove both its metadata and physical storage.

First, the database updates its system catalog so the table is no longer part of the schema. After that, the storage allocated to the table is marked as available for reuse.

Unlike DELETE, individual row removals are not logged, making the operation much more efficient for removing an entire table.

SQL DROP TABLE Syntax

The syntax is simple and supported by most relational database systems.

DROP TABLE table_name;

For example:

DROP TABLE students;

Some database systems also allow several tables to be removed in one statement by separating their names with commas.

Keep in mind that dropping a table may fail if other database objects depend on it, such as foreign key relationships.

Using IF EXISTS

Trying to remove a table that does not exist normally produces an error. Many database systems support the optional IF EXISTS clause to avoid this situation.

DROP TABLE IF EXISTS users;

Using this variation lets scripts continue even when the specified table is already missing, which is useful for deployments and automated database maintenance.

Using a Visual Database Client

Executing destructive SQL statements through a visual database client provides an additional layer of confidence.

Instead of manually typing commands, you can:

• Browse database objects visually.
• Locate the correct table.
• Preview the generated SQL.
• Confirm the action before execution.

These features help reduce mistakes when working with production or shared databases.

Best Practices

Dropping tables is straightforward, but it should always be planned carefully.

Before running the command, consider the following recommendations:

• Create backups for important data.
• Verify dependencies such as foreign keys and views.
• Use IF EXISTS where appropriate.
• Avoid executing DROP TABLE directly in production without verification.
• Manage schema changes through version-controlled scripts whenever possible.

Frequently Asked Questions

What is the difference between DROP TABLE, TRUNCATE, and DELETE?

These commands serve different purposes. DROP TABLE removes both the table and its contents. TRUNCATE removes every row but keeps the table definition. DELETE removes rows while leaving the structure intact.

Logging also differs. DELETE records each row removal, while DROP TABLE and TRUNCATE generally use minimal logging.

Rollback behavior varies as well. DELETE can often be rolled back inside a transaction, whereas DROP TABLE usually cannot.

The appropriate choice depends on whether you want to remove rows or eliminate the table completely.

How do you drop all tables?

There is no universal SQL command for removing every table in a database.

Most systems require generating a list of existing tables from the system catalog and executing DROP TABLE for each one through a script.

The implementation depends on the database platform.

How do you drop a column?

Columns are removed with the ALTER TABLE statement rather than DROP TABLE.

ALTER TABLE table_name
DROP COLUMN column_name;

This permanently deletes the selected column together with its stored values.

How do you drop a temporary table?

Temporary tables are dropped similarly to regular tables, although the exact syntax varies by database system.

Some platforms provide dedicated keywords, while others simply use the normal DROP TABLE statement together with the temporary table name.

Can multiple tables be dropped at once?

Several database systems allow multiple table names in one statement.

DROP TABLE table_one, table_two;

Support depends on the database engine, so always verify the syntax before execution.

Why use a visual database client?

A visual database client makes database administration easier by providing schema navigation, SQL editing, and execution tools in one interface.

It also helps reduce the risk of destructive operations by allowing you to inspect objects before removing them and preview the generated SQL.

Conclusion

The SQL DROP TABLE statement permanently removes a table together with its structure, data, and related objects. Knowing when to use it, understanding the available syntax, and following safe practices can help prevent unwanted data loss during database administration.

For a more detailed walkthrough, syntax variations across database systems, and additional examples, read the original guide here SQL DROP TABLE Statement: Everything You Need To Know.

SQL DROP TABLE Statement Explained: Syntax, Examples, and Best Practices was originally published in The Table — Databases and SQL on Medium, where people are continuing the conversation by highlighting and responding to this story.

Keeping MySQL or MariaDB updated helps maintain compatibility, security, and stability. WHM includes built-in tools that simplify the upgrade process, allowing administrators to update supported database versions with only a few steps.

Access WHM Before Starting

Make sure you can sign in to WHM before beginning the upgrade. To access WHM:

• Open your server address using port 2087.
• Sign in with your server credentials.
• If needed, try adding /whm to the URL if the login page does not appear.

Upgrade MySQL or MariaDB

Once you’re inside WHM, the upgrade utility is easy to locate. Open MySQL/MariaDB Upgrade or Upgrade Database Version, then:

• Select a supported MySQL or MariaDB release.
• Review the validated my.cnf configuration.
• Choose either an automatic or interactive upgrade.
• Wait until WHM confirms the upgrade has completed successfully.

Check Compatibility

Before finalizing the upgrade, it’s worth confirming everything is compatible. Use the MySQL Upgrade Checker to:

• Verify database compatibility.
• Identify configuration issues.
• Review recommendations before completing the upgrade.

Managing Your Database After the Upgrade

Updating the database server is only one part of database administration. A database client can also help you:

• Connect to multiple database platforms.
• Execute and review SQL queries.
• Control query execution permissions.
• Visualize database structures with ER diagrams.

Frequently Asked Questions

How do I upgrade MySQL in WHM?

Log in to WHM, open the database upgrade utility, choose a supported version, review the configuration, and complete either the automatic or interactive upgrade.

What if I don’t use WHM?

Without WHM, you’ll need to back up your database, install the appropriate MySQL packages for your operating system, perform the upgrade using your package manager, and restart the MySQL service.

Does WHM support every MySQL version?

No. WHM only supports selected MySQL and MariaDB releases. Always verify supported versions before starting the upgrade.

Can DbVisualizer upgrade MySQL?

No. DbVisualizer is designed for database management and SQL development rather than upgrading database servers. It can, however, help you manage databases after the upgrade.

Conclusion

WHM provides a straightforward way to upgrade MySQL or MariaDB while validating your configuration during the process. After upgrading, it’s still important to monitor and manage your databases using the right tools.

Read the complete guide here, How to Upgrade MySQL in WHM? Step-By-Step Guide.

How to Upgrade MySQL in WHM: A Simple Step-by-Step Guide was originally published in The Table — Databases and SQL on Medium, where people are continuing the conversation by highlighting and responding to this story.

Modern applications often need to serve multiple customers while keeping their data separate. Multitenant database containers make this possible by combining containerized databases with Kubernetes management capabilities, helping teams scale and manage workloads efficiently.

Understanding Multitenancy

Multitenancy allows a single application or database instance to support multiple customers while keeping their data isolated.

Think of it as a shared apartment building where every resident has a private living space despite using the same building infrastructure.

Why Containers Are Common for Database Multitenancy

Containers provide a consistent environment for running databases across different systems. When paired with Kubernetes, they simplify deployment and management. Key advantages include:

• Better resource utilization than traditional virtual machines
• Automatic scaling based on workload demand
• Tenant isolation through Kubernetes controls
• Centralized configuration management

Building a Multitenant Database Deployment

A Kubernetes-based database deployment typically relies on three components.

Persistent Storage

Reliable storage ensures data remains available after restarts or redeployments. Example Persistent Volume configuration:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: mysql-pv
spec:
  capacity:
    storage: 1Gi

Persistent Volume Claims

A PVC requests storage from the available Persistent Volume.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-pvc

Database Deployment

The deployment defines how the database container runs.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mysql-deployment

Service Configuration

A Kubernetes Service provides a stable endpoint for applications.

apiVersion: v1
kind: Service
metadata:
  name: mysql-service

Applying the Configuration

Once the YAML files are ready, deploy them using:

kubectl apply -f mysql-pv.yaml
kubectl apply -f mysql-pvc.yaml
kubectl apply -f mysql-deployment.yaml
kubectl apply -f mysql-service.yaml

After deployment, verify resources with:

kubectl get pv
kubectl get pvc
kubectl get svc

FAQ

What Are Multitenant Database Containers?

Multitenant database containers allow one application or database environment to support multiple tenants while maintaining separation between their data and workloads.

How Do You Configure Them in Kubernetes?

A typical setup includes a Deployment, a Persistent Volume, and a Service. These resources are defined using YAML files and deployed through Kubernetes.

Why Use DbVisualizer?

DbVisualizer provides database management capabilities through a graphical interface. It supports multiple database platforms, data exports, query assistance, and direct data editing.

Conclusion

Multitenant database containers provide a practical way to support multiple customers within a shared Kubernetes environment. By combining deployments, persistent storage, and services, teams can build scalable and manageable database platforms.

Read the original article for additional details and examples: Multitenant Database Containers for Modern-Day Applications.

Multitenant Database Containers Explained for Kubernetes Applications was originally published in The Table — Databases and SQL on Medium, where people are continuing the conversation by highlighting and responding to this story.

Reliable backups are an important part of database management. MyDumper helps MySQL and MariaDB users create backups faster through multithreading, while checksum validation adds confidence that restored data matches the original source.

Why MyDumper Is Popular

MyDumper is a logical backup tool designed to improve backup performance compared to traditional single-threaded alternatives.

Key benefits include:

• Multithreaded backup operations
• Support for large and small databases
• Table chunking for faster processing
• Flexible backup configuration
• Compression support

Because it can process data in parallel, MyDumper is often chosen for larger database environments.

Using Checksums to Verify Backup Integrity

Data validation becomes important when backups are restored. MyDumper can generate and compare checksum values to help confirm that restored data remains unchanged. A simple example:

./mydumper --host localhost --user mysqluser --password BrV9u2MbT \\
--outputdir /tmp/backups/ --M

The command includes:

• Database host information
• User credentials
• Backup destination
• The -M option for checksum validation

During backup and restoration, checksum values are compared. If differences are detected, the integrity check fails.

Useful MyDumper Features

Beyond checksum validation, MyDumper includes several options for backup customization. Common capabilities include:

• SSL-only connections
• Database filtering
• Record filtering with -where
• Long query management
• Thread configuration per table

These options help adapt backup jobs to different environments and workloads.

MyDumper and MyLoader Together

For larger databases, MyDumper is frequently paired with MyLoader. The workflow is straightforward:

1. MyDumper creates the backup.
2. MyLoader restores the backup.
3. Validation checks help confirm consistency.

This combination can significantly reduce backup and restore times compared to single-threaded tools.

SQL Clients and Database Management

Backup validation is only one part of database administration. Tools such as DbVisualizer provide features including:

• SQL history tracking
• Query bookmarking
• Data exports
• Visual database interaction

While these tools do not replace backup software, they can improve day-to-day database management.

FAQ

What is MyDumper and how does it differ from mysqldump?

MyDumper is a logical backup utility that uses multiple threads. Unlike mysqldump, it can process backup tasks in parallel, which often improves performance.

Are MyLoader and MyDumper the same?

No. MyDumper creates logical backups, while MyLoader restores them. They are separate tools that are commonly used together.

How do you use MyDumper?

MyDumper is executed from the command line. Users provide connection details, backup settings, and optional parameters such as checksum validation.

Conclusion

MyDumper offers a practical approach to MySQL and MariaDB backups through multithreading and flexible configuration. When checksum validation is enabled, it also provides an additional layer of confidence during restoration. For the complete guide, read the original article here: Using MyDumper Checksums for Reliable MySQL Backup Validation.

Using MyDumper Checksums to Validate MySQL Backups was originally published in The Table — Databases and SQL on Medium, where people are continuing the conversation by highlighting and responding to this story.

Database failures happen unexpectedly, making a reliable backup strategy essential. This guide walks through creating PostgreSQL backups, restoring lost data, and handling common recovery issues using pg_dump and pg_restore.

Building a PostgreSQL Backup Environment

A safe backup process starts with a working PostgreSQL setup. To prepare the environment:

• Create a project directory
• Configure PostgreSQL with Docker Compose
• Start the PostgreSQL container
• Connect using psql

Once connected, create a sample database and populate it with test records.

Creating the Initial Backup

Before making changes, create a backup that can be used for recovery.

The custom format is often the preferred choice because it supports compression and flexible restores. This backup captures both data and database metadata.

Simulating Database Failure and Recovery

A recovery process is easiest to understand through a practical example.

Common causes of data loss include:

• Server crashes
• Hardware problems
• Accidental deletion
• Database corruption

After deleting the database and its role, an attempted restore may fail because PostgreSQL cannot find the original owner role. Recreating the missing role and retrying the restore allows the database to be recovered successfully.

PostgreSQL Backup Formats

Different backup formats serve different purposes. Common options include:

• Plain text SQL for readability
• Custom format for flexibility
• Directory format for large databases
• TAR format for easier file handling

For most environments, the custom format offers the best balance of features and simplicity.

Restoring Different Backup Types

Not every backup format uses the same restore method.

For example, plain-text backups are restored with psql:

psql -d surveyplatform -f backup.sql

Custom backups use pg_restore:

pg_restore -d surveyplatform custom.dump

Verifying restored data ensures the backup contains the expected database state.

FAQ

Which PostgreSQL backup format should I use for daily backups?

Custom format is usually the most practical choice. It provides compression, supports selective restores, and works directly with pg_restore. It also scales well for routine backup schedules.

Many administrators use it as their default backup option. The format combines convenience with reliable recovery capabilities.

How often should I test my PostgreSQL backups?

Monthly testing is a sensible minimum. A test restore helps verify that backup files remain usable. Checking row counts or key tables can quickly confirm data integrity.

Regular testing reduces surprises during real incidents.

Why do I get “role does not exist” errors when restoring backups?

The original database owner may be missing from the target system. PostgreSQL stores ownership information inside backups.

Creating the missing role before restoring usually resolves the issue. After the role exists, the restore process can continue normally.

Can I restore a PostgreSQL backup to a different database name?

Yes, PostgreSQL supports restoring into a new database.

Create the target database first. Run pg_restore without the database creation flag. This allows the backup contents to be loaded into a differently named database.

Conclusion

PostgreSQL provides reliable backup and recovery tools through pg_dump and pg_restore. Understanding backup formats, testing restores, and handling role-related issues can help reduce downtime when problems occur. For the complete walkthrough and examples, read the original article here: PostgreSQL Backup and Restore: Complete Tutorial with pg_dump and pg_restore.

PostgreSQL Backup and Restore with pg_dump and pg_restore was originally published in The Table — Databases and SQL on Medium, where people are continuing the conversation by highlighting and responding to this story.

MySQL 8.0 reaches its end-of-life milestone in April 2026. After that point, organizations still running the database version will no longer receive updates or official fixes. Understanding the impact can help teams plan upgrades and reduce operational risks.

Why MySQL 8.0 EOL Matters

Once support ends, organizations may face a number of challenges.

Some of the most common concerns include:

• No new security patches
• Limited vendor support
• Potential compliance complications
• Increased maintenance responsibility

Businesses operating under regulations such as PCI DSS or HIPAA should carefully evaluate the risks of continuing to run unsupported database software.

What Are Your Options?

When MySQL 8.0 reaches EOL, several paths remain available.

Upgrade to MySQL 8.4

The most direct option is moving to MySQL 8.4, the long-term support release in the MySQL 8 family.

Benefits include:

• Continued security updates
• Ongoing vendor support
• Better compliance positioning

Consider Alternative Database Platforms

Some organizations may choose alternatives such as:

• MariaDB
• Percona Server

Each offers a different approach to performance, support, and feature development.

Continue Running MySQL 8.0

Some teams may remain on MySQL 8.0 after support ends.

If that happens, expect:

• Greater security exposure
• Internal responsibility for maintenance
• Additional audit scrutiny

The Role of SQL Clients

Database tools cannot extend MySQL’s lifecycle, but they can improve day-to-day database management.

Tools such as DbVisualizer help users:

• Browse databases and tables
• Manage permissions
• Write SQL more efficiently
• Access visual query-building features

These capabilities can make database administration easier, regardless of the MySQL version being used.

FAQ

Has MySQL 8.0 Reached EOL?

MySQL 8.0 officially reaches end of life in April 2026. Whether it is already unsupported depends on when you’re reading this article.

Support status should always be verified against the current release schedule.

What Should I Do If I Want to Run MySQL 8.0 After EOL?

The safest approach is upgrading to a supported release.

If upgrading is not immediately possible, organizations should implement additional security controls and understand that official fixes and updates may no longer be available.

Long-term operation on unsupported software increases risk over time.

Where Can I Learn More About MySQL EOL Products?

The best source is Oracle’s official MySQL end-of-life documentation and release announcements.

Those resources provide current support timelines and upgrade recommendations for affected products.

Conclusion

MySQL 8.0 end of life marks the end of official support and security updates. Organizations should evaluate upgrade options, review compliance requirements, and prepare a long-term database strategy. For more details, read the original article MySQL 8.0 EOL: What Happens Next?

MySQL 8.0 End of Life: What Changes After April 2026? was originally published in The Table — Databases and SQL on Medium, where people are continuing the conversation by highlighting and responding to this story.