A Postgres table, carefully protected behind a thick undergrowth of privileges and policies. Photo by ZACHARY PEARSON on Unsplash

Every Friday evening when I sit down to build out a new database schema, I always find myself looking up the same questions so I collected them here to save myself the trouble.

I’m calling this a “beginner’s guide” because every time I build something on Postgres I learn new things. I’ve deployed many of these practices into widely-available production applications so any feedback you can provide is valuable, especially if it’s critical.

User Types, defined as roles

Creating separate database roles for each type of user allows us to enforce a deep level of control and security for the underlying data. This is important…


Newly launched Lambdas flying into an unreserved concurrency pool. Photo by Nick Fewings on Unsplash

I have been using Lambda in production for about four years now personally, and three years professionally at Volta. Initially, I shipped Lambdas because it was easier than managing servers. At Volta, we now exclusively use server-less services because they are the smartest option for our workloads if we remember to support them correctly. This is a cheat sheet, a checklist of all the things you might want to remember when shipping something new to ensure it runs successfully.

Infrastructure as Code

Regardless of what support you like to build into your Lambdas, the most important thing to do is to ensure consistency…


An unprepared candidate sitting down to an interview with me. Photo by Caleb Woods on Unsplash

Over the past few years, I’ve taken part in hundreds of interviews. I’ve been both interviewer and interviewee over the phone, on video chat, and in person more times than I can remember and I’ve refined my tactics along the way. No matter the method or the role I have in the interview, I always try to expose the following traits which I consider most valuable in a great technical peer. These are my own opinion, and I’d appreciate to hear yours in the comments!

Solve problems multiple times, slowly, and vocally

As a junior engineer, straight out of school, seeing a solution may be difficult at…


An aerial view of Google’s Git repository. Photo by Dan Meyers on Unsplash

We’re starting to explore monorepositories. Not in a big, “let’s chuck all our services into one repo” kind of way, but in a smaller, “let’s merge some related services to save some cognitive overhead”, kind of way. The stack driving our decisions: we mostly deploy Lambdas to AWS using CircleCI and a splash of CloudFormation, we write our functions in TypeScript, and Yarn has been our dependency management weapon of choice since day one.

Our goal is to cut down the number of repositories we have to manage while retaining the flexibility of different tooling and deployment strategies for each…


Two software engineers playing outside after they saved countless hours by going server-less with GraphQL. Photo by Jenn Evelyn-Ann on Unsplash

*It will actually take around an hour

The best things about writing code is not having to write very much of it. Let’s discuss how to get there using a few magical libraries and a couple of managed services from our favorite cloud provider and supreme leader of the universe, AWS.

This is not meant to be a step-by-step tutorial, but more of a guide for when you get lost in the woods. But first, let’s get on the same page. Our entire application has a few basic requirements:

  1. The application has users
  2. Users can create things
  3. Access to things


Elephants standing performantly between some trees. Photo by Jeff Lemond on Unsplash

In an effort to write less application logic in my services and interfaces, (and out of pure laziness), I am persistently looking for performant strategies to bake access control directly into my schemas. Row Level Security has been around in Postgres for a while now, but we have recently gotten some upgrades to the optimizer which make it worth a deeper investigation.

Update October 22nd, 2020: If you’re feeling lost on the basics of policies and privileges in Postgres, refer to this guide to get warmed up.

But why?

If you’re not familiar with Row Level Security, the main hypothesis is that…


Automate all of the things! Source: https://www.flickr.com/photos/56682936@N03/15572646535

Our team is small but our application is large. To balance this constraint, we have harnessed the power of managed services and an event-driven architecture to focus engineering cycles on core business logic. Initially, that means investing in infrastructure that will support new features and increasing scale. Here I will discuss some of the key decisions that have helped and hindered our progress.

Bottlenecks

As a small engineering team, our tightest bottleneck is human-cycles. Functionally, we face challenges like handlings bursts of events from sensors in our network or needing to display raw and aggregated data on a variety of interfaces…


Austin, circa 2015

I don’t make it back to Austin often since I left in the spring of ’16 so, when I returned recently for Eeyore’s Birthday, I made sure to make all the stops I miss most. This is a rundown of those and a few others I couldn’t make it to. Disclaimer: some of these may have changed or disappeared since I moved away.

Food

Every restaurant in Austin that I’ve visited has something special to share; however, a few key locations stand out in my mind for their incredible execution of a particular cuisine.

The revolution starts with breakfast, more specifically…


Application Users as PostgreSQL Roles

Update: I initially wrote thing a year ago while exploring Row Level Security in Postgres, but unpublished it due to performance concerns. I am republishing it now since new methods have come to light and it may serve as a useful reference.

More update: I just finished a more thorough investigation of how to implement RLS performantly, it leverages some new optimizations in PostgreSQL 10.

Here’s a dangerous idea: let’s give each application user a role in the database. PostgreSQL 9.5 …


This is actual utilization data from a Volta station at Macy’s Pasadena Plaza on Lake Avenue

I recently received a request from a member of the site sales team at Volta for hourly station utilization. This metric is interesting to me because it requires calculation, specifically the percentage of time when someone is charging at that station. Since our data is stored in PostgreSQL, why not make it do the heavy lifting to answer this question? Turns out there are some great utilities baked in which make this an easy question to answer.

What is the utilization per hour for station X on August 13th, 2015?

For a single charging station on a single day this…

Caleb Brewer

I build things by breaking them.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store