Migration From MySQL To PostgreSQL In Five Steps Using DBeaver

I wrote a post in my MySQL blog on migrating from MySQL to PostgreSQL using DBeaver. You can pass it along to your acquaintances who want to get off the Dolphin and on the Elephant.

Not only will DBeaver move your tables and data, but you can compare them afterwards. In the post, I outline the process in five steps. DBeaver will let you do it in four.

Please share this blog with your friends to promote PostgreSQL.

Popular posts from this blog

Incremental Backups in PostgreSQL 17

The old adage that a DBA or SRE is only as good as their last backup is true. PostgreSQL 17 added the ability to combine multiple incremental backups with a full backup to provide a complete data dictionary to recover a failed system. It is very easy to use. This is a quick example of using incrementals. I recommend watching this video by Robert Haas for more details and some discussion of backup strategies. Step 1 - Enable WALL Summerization The incremental backups require Write Ahead Log Summarization. It is likely not on your instance by default. But it is easy to enable. demo=# alter system set summerize_wal = ‘on’; ALTER SYSTEM demo=# select pg_reload_conf(); pg_reload_conf –––––––– t (1 row) Step 2 - Full Backup The examples below are much simpler than you will run into in real life. The scenario is that we make a full backup on Sunday and do incrementals the rest of the week. Wednesday through Saturday are omitted below. stoker@ThinkPa...

Can Artificial Intelligence Created Better Tables Than You?

Artificial Intelligence is one of those conundrums where the ability to have some tasks handled for you contrasts with a mix of ego and pride that it may be better than you at those tasks. I recently wrote a blog using another database about an AI-generated SQL that was quite sophisticated . But what about asking an AI to create a table with a specification like a DBA/SRE/Analyst might receive? I used Grok and entered the following prompt: Write the SQL to create a table on a PostgreSQL version 17 server to record data on customers. The data will include a first name, a last name, an address, a birthdate, and a unique UUID primary key. Partition the data by the year of birth. And produce some test data of at least ten records. I am sure many of us have started large projects given less instruction. Notice: I did not denote the format for the address (US Post Office’s format, or UK, or other). Nor did I set a name length. I wanted to see what assumptions were made by t...

How PostgreSQL’s Aggregate FILTER Will Spoil You

Using PostgreSQL will definitely spoil you. I recently had to use another database and found, to my chagrin, that aggregate filters were not included in their implementation of Structured Query Language. Specifically, there was no FILTER clause available. FILTER? To illustrate my dependency, let me start with some simple data. demo=# create table z (a int, b int, c int); CREATE TABLE demo=# insert into z values (1,10,100),(2,20,200),(3,30,300),(4,40,400); INSERT 0 4 demo=# select a,b,c from z; a | b | c —+––+—– 1 | 10 | 100 2 | 20 | 200 3 | 30 | 300 4 | 40 | 400 (4 rows) demo=# If I wanted the overall number of rows, I could use a simple COUNT(*). If I wanted an overall number of rows where one of the columns was of a certain value, I could add the logic for getting those rows to the WHERE clause. What if I wanted both? Do I need two queries to do the work separately? Maybe a materialized view or a CTE (Common Tabl...