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.
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.
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.