In my previous post, Handling Database Schema Changes, I explained the strategy for managing database schema changes using GNU Make. However, after further consideration and testing, I have found that this approach may not be suitable for all deployment environments, particularly those that have strict security restrictions such as AWS Lambda.
Redash is an excellent tool to quickly build stunning dashboards to present your data. I use it to visualize data from my PostgreSQL databases for various projects, with the reliance in containers being a bit of a letdown for me. This post collects some notes on deploying redash as a group of standalone processes governed by systemd on my Linux servers. I can even run multiple instances on a single box, which is useful for testing new code versions or providing fully separate dashboards to different projects.
PostgreSQL provides TYPE and DOMAIN abstraction which impose structural and semantic constraint over your data. Wisely using these mechanisms provides solid guarantees on data quality, enforceable at the database itself. Let’s continue the Notes on Database Design series with the use of DOMAIN to validate your data.
This is the beginning of a series of posts where I’ll explore various lessons — choices — that can be made to better leverage PostgreSQL for your own projects. In this series I’ll go over some loose principles that I always keep present and that hopefully, will be of help.
This is the second post in my series Notes on Database Design, where I introduce a simple database schema to support selling event tickets for my fantasy company, TicketDoctor.
The PostgreSQL that ships with most linux distributions is setup with Snakeoil TLS certificates by default. Managing these certificates is not any different to any other service, yet for some reason this is an often neglected task that leaves your database connections exposed to certain types of attack. This post discusses the — very few — steps required to use Let’s Encrypt certificates to secure your PostgreSQL sessions as well as an easy way to monitor your servers.
Most of the applications I work with involve storing, transforming and querying data from relational databases. Over the years I’ve developed a pattern to manage those changes that has proven to be helpful, involving a minimum of universally available tools. This post introduces this pattern in the hopes that it becomes useful for others.