Slack Chatbot with PostgreSQL Backend

Share this post:

Access PostgreSQL from IBM Cloud Functions

Our solution tutorial for building a database-driven slack chatbot utilizes Db2 on Cloud as a database service. Featuring a serverless architecture, all the interaction with Db2 is implemented using IBM Cloud Functions. If you are fan of open source database systems, PostgreSQL in particular, there is great news. The serverless actions are now available for PostgreSQL, too. Read on for the details.

Database-driven Slack chatbot

The IBM Cloud solution tutorial on building a database-driven Slackbot integrates Slack with IBM Watson Assistant. During a conversation, users find out about upcoming conferences or events. Moreover, using either a question and answer style, or by providing all relevant information at once, users can also insert new event data into a database. In the tutorial, Db2 on Cloud is the backend database. However, there are many other database services available in the IBM Cloud catalog. One of them is Databases for PostgreSQL. It is a fully managed version of the popular open source database system. The service offers high availability, security, and scalability. Why not look into what needs to be done to replace the database service for the tutorial? Here is how the architecture looks with PostgreSQL in place:


Slackbot architecture with PostgreSQL

Slackbot architecture with PostgreSQL

Code changes

To adapt the tutorial to use PostgreSQL instead of Db2, only few changes were necessary. First, I needed to provision the Databases for PostgreSQL service. Thereafter, I needed to go over all the cloud functions in the tutorial that access Db2 and modify the code. The runtime environments offered by IBM Cloud Functions already include PostgreSQL libraries. The Node.js environment offers the node-postgres (pg) module. Thus, to avoid extra libraries and dependencies, I opted to use the pg module.

Programming languages like Java or Python offer standard database interfaces like JDBC or DBI. For Node.js, it is not the case and, hence, there are some API differences to node-ibm_db, the Db2-related module. On the plus side, passing in the service credentials to the action and returning the result does not change. Thus, the code changes are to adapt to the PostgreSQL-specific functions and their parameters and to slightly modify the SQL statements to match the other dialect. Changes to the Watson Assistant chatbot are not necessary because it invokes an action by package and function names which don’t change.


Having a working blueprint like an IBM Cloud solution tutorial, it is fairly straightforward to replace one component with another service. Scripting for the setup, automated service bindings to get to the credentials, and working with well-defined APIs makes it simple to make the switch.

If you have feedback, suggestions, or questions about this post, please reach out to me on Twitter (@data_henrik) or LinkedIn.

Technical Offering Manager / Developer Advocate

More Databases stories
March 19, 2019

Cloudant Best (and Worst) Practices — Part 2

As outlined in "Cloudant Best (and Worst) Practices—Part 1," I’ve had the unique opportunity to see IBM Cloudant from all angles—the customers who use it, the engineers that run it, and the folks who support and sell it—and I'm here to summarize the best—and worst! — practices we see most often in the field.

Continue reading

March 18, 2019

Cloudant Best (and Worst) Practices — Part 1

As providers of the Cloudant database service, we'd like to summarize the best—and worst!—practices we see most often in the field. This is Part 1 of a two-part post.

Continue reading

February 27, 2019

IBM Cloud Databases for MongoDB is Generally Available

IBM Cloud is announcing the General Availability of IBM Cloud Databases for MongoDB in Dallas, Frankfurt, London, Oslo, Sydney, Tokyo, and Washington D.C.

Continue reading