top of page
Search
  • Writer's pictureTim Burns

Postgres is Not a Dinosaur (At least not with AWS)



Ten years ago, we had a development database server we affectionately named "Terabytes Rex." No irony. The mass extinction of on-premises database servers is well on its way. Like the extinction of the dinosaurs, the disintegration of the old order is blending with other catalysts of change and yielding a Cenozoic diversity of databases. A database now can be a massive in-memory store like Redis, a document like MongoDB, a column store databases such as Cassandra, or data warehouses like Redshift and Snowflake.


Is the old-school relational database like Postgres obsolete? Is it a waste of time to analyze primary and foreign keys? Should we spend time thinking about data types for columns or treat all data as strings? Is the entity-relationship diagram the modern equivalent of dinosaur footprints in the mud?


No way. The medium has changed. Even though we no longer need an impressive flashing server rack, a relational database is still the backbone of application development.


So how do we do Postgres in the age of the cloud? You use AWS to create a Relational Database Service (RDS).


If massive Dell SAN server running Oracle is a dinosaur, then Postgres on RDS is a Sandhill Crane to take its place. The crane isn't as big and sexy as the dinosaurs that passed, but it has thrived for the last 10 million years. Oracle and big iron had their heyday, but now I can spin up a humble RDS Postgres database in AWS that will satisfy the same crucial niche in my applications.


How to get started with Postgres on RDS? First, you must realize that Cloud computing is all about security. Know your security constraints spinning up an RDS instance. Do you want to have a test database that is open to the world? Are you storing sensitive data and need it in a Virtual Private Cloud on a private subnet? Where the dinosaur developer agonized over Object-Oriented Design and Entity Relation Diagrams, the modern developer's core skills are network configuration and security settings.


Postgres runs on port 5432 by default. If you are on AWS, you have set up a virtual private cloud (see my old article Building a Secure VPC).


Using your VPC, go into the VPC services setting and create a security group to allow Postgres access.

Now create a rule to limit access. You can specify a custom mask, allow from anywhere, or use the current IP.

Create a Postgres RDS instance and add this group.



The default groups above included are the default groups to be used within the subnet. The purpose is for client usage with AWS Lambda, which I will address in a future article.


Now you can go into your favorite database client like DBeaver or IntelliJ Professional and connect to your Postgres instance. If it times out, it is because your security settings are not correct. You need to go back and make sure that you have allowed access to port 5432.

54 views0 comments

Recent Posts

See All
bottom of page