Access your data on PostgreSQL

The first step in migrating your PostgreSQL data to any kind of data warehouse solution is to access your data and start extracting it.

There are many ways of doing this, like, for example, a logical replication log as previously mentioned. In this case, you need to listen to the log for changes on the database and you reflect them on the target system. When pulling data from a database you also need to be able to filter tables, columns, find a way to identify updates, and replicate the appropriate database schema considering also that it will end up in a columnar database for analytics.

Another way is by using a JDBC importer. In this case, any input configuration will contain all the appropriate values for the database authentication and connection. By appropriately configuring the JDBC importer you can control each table’s behavior during import and altering its schema as well if desired.

Moreover, pagination of data importing can be simulated by querying tables in batching mode.

Transform and prepare your PostgreSQL data

After you have accessed your data on PostgreSQL, you will have to transform it based on two main factors,

1. The limitations of the database that the data will be loaded onto
2. The type of analysis that you plan to perform

Each system has specific limitations on the data types and data structures that it supports. Also, you have to choose the right data types. Again, depending on the system that you will send the data to, you will have to make the right choices.

While for the most common data types the mapping choices may seem to be obvious, each database system will most probably support a set of more “sophisticated” and database-specific types whose mapping choices requires careful consideration since they can limit the expressivity of your queries and restrict your analysts on what they can do directly out of the database.

However, if you plan to push the data to another PostgreSQL database, then you probably don’t have to worry about the data types, unless you have some reasons related to the analysis that you will perform.

Data in Snowflake is organized around tables with a well-defined set of columns, with each one having a specific data type.

Snowflake supports a rich set of data types. It is worth mentioning that a number of semi-structured data types is also supported. With Snowflake, it is possible to load data directly in JSON, Avro, ORC, Parquet, or XML format. Hierarchical data is treated as a first-class citizen, similar to what Google BigQuery offers.

There is also one notable common data type that is not supported by Snowflake. LOB or large object data type is not supported. Instead, you should use a BINARY or VARCHAR type. But these types are not that useful for data warehouse use cases.

A typical strategy for loading data from PostgreSQL to Snowflake is to create a schema where you will map each API endpoint to a table.

Each key inside the PostgreSQL API endpoint response should be mapped to a column of that table, and you should ensure the right conversion to a Snowflake data type.

Of course, you will need to ensure that as the data types from the PostgreSQL API might change, you will adapt your database tables accordingly. There’s no such thing as automatic data type casting.

After you have a complete and well-defined data model or schema for Snowflake, you can move forward and start loading your data into the database.

Load data from PostgreSQL to Snowflake

Usually, data is loaded into Snowflake in a bulk way, using the COPY INTO command. Files containing the data, usually in JSON format, are stored in a local file system or in Amazon S3 buckets. Then a COPY INTO command is invoked on the Snowflake instance, and data is copied into the data warehouse.

The files can be pushed into Snowflake using the PUT command into a staging environment before the COPY command is invoked.

Another alternative is to upload the data directly into a service like Amazon S3, from where Snowflake can access the data directly.

Updating your PostgreSQL data on Snowflake

As you will be generating more data on PostgreSQL, you will need to update your older data on Snowflake. This includes new records together with updates to older records that, for any reason, have been updated on PostgreSQL.

You will need to periodically check PostgreSQL for new data and repeat the process that has been described previously while updating your currently available data if needed. Updating an already existing row on a Snowflake table is achieved by creating UPDATE statements.

Another issue that you need to take care of is the identification and removal of any duplicate records on your database. Either because PostgreSQL does not have a mechanism to identify new and updated records or because of errors on your data pipelines, duplicate records might be introduced to your database.

In general, ensuring the quality of the data that is inserted into your database is a big and difficult issue.

The best way to load data from PostgreSQL to Snowflake

So far, we just scraped the surface of what can be done with Snowflake and how to load data into it. The way to proceed relies heavily on the data you want to load, from which service they are coming from, and the requirements of your use case.

Things can get even more complicated if you want to integrate data coming from different sources. A possible alternative, instead of writing, hosting, and maintaining a flexible data infrastructure, is to use a product like RudderStack that can handle this kind of problem automatically for you.

RudderStack integrates with multiple sources or services like databases, CRM, email campaigns, analytics, and more. Quickly and safely move all your data from PostgreSQL to Snowflake and start generating insights from your data. Don't want to go through the pain of direct integration? RudderStack’s PostgreSQL to Snowflake integration makes it easy to send data from PostgreSQL to Snowflake