Postgres - one database to rule them all
One of the advantages of Postgres is the many high quality extensions which makes it suitable for storing a range of data.
You can store:
- JSON - builtin
- Spatial data - PostGIS
- Time series data - TimescaleDB
- Even graph data is in the works - Apache AGE
Without these extensions you would require many different specialised databases. Supporting multiple databases means more maintenance work.
By having all of your data in one place, it makes querying it easier. With a single SQL query you can join together time series data, spatial data, and any other relational data. If this data is spread over many databases, you need to join the data together using code, which is less performant, and more work.
There is also great convenience in only needing to learn one query language - SQL. Many specialist databases have their own query language, which take significant time and effort to learn. It's likely that a large proportion of developers on a team know at least some SQL.
By having all of your data in Postgres, it also means you can use the tools you're familiar with. If your time series data is in a separate database, it's another set of tools you need to learn. Postgres has a huge ecosystem of tools - GUIs such as PgAdmin, drivers for most programming languages, and ORMs / query builders like Piccolo!
The extensibility of Postgres is really its killer feature. It's almost an operating system for your data. The fact that it can do so much, and does it so well, is remarkable. This is one of the reasons it's growing so quickly.
When I'm building systems, I argue hard to use Postgres for as much as possible. It results in a more streamlined architecture, with greater developer productivity, and easier onboarding. Postgres was initially released in 1996, but it feels like it's just getting started.
Posted on: 8 Apr 2021
Have any comments or feedback on this post? Chat with us on GitHub.