4 ms·

Building a database is brave or stupid or both. Over the last 15 or 20 years I’ve tried lots of databases of all flavors and every time come back to Postgres.

Building a database is brave or stupid or both. Over the last 15 or 20 years I’ve tried lots of databases of all flavors and every time come back to Postgres. What can’t it do. And like Linux it’s written in C. Not that means much. “Never bet against Postgres”.

jen20 4y ago
> What can’t it do. Fail over without downtime or operator intervention.
ly3xqhl8g9 4y ago
However, you didn't return to postgres:6.0 (first formal release in 1997 [1]), you returned to postgres:latest, which included the lessons learned from lots of other databases, thinking here of postgres:9.2 (in 2012) adding native JSON support making Postgres basically NoSQL with extra steps. Contrary to popular wit, reinventing the wheel is always beneficial, if it will not bring something new to the world, it will at least make you understand and appreciate wheels better. [1] https://en.wikipedia.org/wiki/PostgreSQL#Release_history https://en.wikipedia.org/wiki/PostgreSQL#Release_history
nhourcard 4y ago
It depends on your use case. For example, Postgres will hit limitations for large streams of time series data on the ingestion side, and the standard SQL language of Postgres may make it challenging to navigate a dataset by time: sampling the data, time intervals, time-series joins (ASOF join), and these kinds of things are not easy or possible to do on Postgres. Why not combine Postgres for OLTP workloads alongside another database for fast analytics/time series, optimised to deal with high throughput ingestion and low latency queries? NB: I am one of the co-founder of an open-source time series database (questdb)
- sgt 4y ago
  TimescaleDB
- jjgreen 4y ago
  Any thoughts on Timescale?
  - globuous 4y ago
    Unfortunately, you cannot install timescale on an rds, or I believe , other managed Postgres services : https://stackoverflow.com/a/67712962 https://stackoverflow.com/a/67712962.
    - sgt 4y ago
      https://www.timescale.com/ https://www.timescale.com/ - they offer this as part of Timescale Cloud
lmm 4y ago
Clustering it is still a pain, certainly if you want a proper autoscaling master-master setup. (Which may not be necessary for performance, but is still what you need for availability/resilience). And it's still too easy to shoot yourself in the foot, by deadlocking, or using up all the server's resources with a query that looks very similar to one that was fine.
dadarecit 4y ago
Seems like there are a couple of people with this mindset at every company. “Let’s write X”, “are you crazy, no one writes X! We can use Y!”, “But Y lacks Z”, “No! The thing you want Y to do is bad! You should not want Z! Do W instead - it is the correct way” Stop larping as graybeards, and try to actually do something instead of endlessly bike shedding your cargo cult.
buremba 4y ago
They don't bet against Postgres
Annatar 4y ago
[dead]
pjmlp 4y ago
Betting against Postgres all the time, since the .com age I have mostly used Oracle and SQL Server, and Postgrest only in a single projec that was alive during 4 years. There was also Informix, SYBASE and DB2, but those hardly matter nowadays.
- aliqot 4y ago
  Why doesn't DB2 matter?
  - pjmlp 4y ago
    It still does, however it is mostly for IBM customers on Aix, IBM i and z/OS, not was widespread as it once was.
newaccount2021 4y ago
[dead]
crabbone 4y ago
> What can’t it do. Async I/O.
ejb999 4y ago
>>Over the last 15 or 20 years I’ve tried lots of databases of all flavors and every time come back to Postgres. Almost the same here, have tried just about everything that comes along, and sooner or later I end up swapping out the database de jour and go right back to sql server in almost all use cases (for the type of projects I do). I feel like db's are pretty much a solved problem, and can't imagine trying to build and market a brand new one these days. Almost as hard as trying to come up with a new operating system and convincing people to switch. I wish good luck to anyone that tries, but talk about pushing a boulder up a mountain; definitely doesn't seem like the easy path to success.

jen20 4y ago

> What can’t it do. Fail over without downtime or operator intervention.

ly3xqhl8g9 4y ago

However, you didn't return to postgres:6.0 (first formal release in 1997 [1]), you returned to postgres:latest, which included the lessons learned from lots of other databases, thinking here of postgres:9.2 (in 2012) adding native JSON support making Postgres basically NoSQL with extra steps. Contrary to popular wit, reinventing the wheel is always beneficial, if it will not bring something new to the world, it will at least make you understand and appreciate wheels better. [1] https://en.wikipedia.org/wiki/PostgreSQL#Release_history https://en.wikipedia.org/wiki/PostgreSQL#Release_history

nhourcard 4y ago

It depends on your use case. For example, Postgres will hit limitations for large streams of time series data on the ingestion side, and the standard SQL language of Postgres may make it challenging to navigate a dataset by time: sampling the data, time intervals, time-series joins (ASOF join), and these kinds of things are not easy or possible to do on Postgres. Why not combine Postgres for OLTP workloads alongside another database for fast analytics/time series, optimised to deal with high throughput ingestion and low latency queries? NB: I am one of the co-founder of an open-source time series database (questdb)

sgt 4y ago
TimescaleDB
jjgreen 4y ago
Any thoughts on Timescale?
- globuous 4y ago
  Unfortunately, you cannot install timescale on an rds, or I believe , other managed Postgres services : https://stackoverflow.com/a/67712962 https://stackoverflow.com/a/67712962.
  - sgt 4y ago
    https://www.timescale.com/ https://www.timescale.com/ - they offer this as part of Timescale Cloud

lmm 4y ago

Clustering it is still a pain, certainly if you want a proper autoscaling master-master setup. (Which may not be necessary for performance, but is still what you need for availability/resilience). And it's still too easy to shoot yourself in the foot, by deadlocking, or using up all the server's resources with a query that looks very similar to one that was fine.

dadarecit 4y ago

Seems like there are a couple of people with this mindset at every company. “Let’s write X”, “are you crazy, no one writes X! We can use Y!”, “But Y lacks Z”, “No! The thing you want Y to do is bad! You should not want Z! Do W instead - it is the correct way” Stop larping as graybeards, and try to actually do something instead of endlessly bike shedding your cargo cult.

buremba 4y ago

They don't bet against Postgres

Annatar 4y ago

[dead]

pjmlp 4y ago

Betting against Postgres all the time, since the .com age I have mostly used Oracle and SQL Server, and Postgrest only in a single projec that was alive during 4 years. There was also Informix, SYBASE and DB2, but those hardly matter nowadays.

aliqot 4y ago
Why doesn't DB2 matter?
- pjmlp 4y ago
  It still does, however it is mostly for IBM customers on Aix, IBM i and z/OS, not was widespread as it once was.

newaccount2021 4y ago

[dead]

crabbone 4y ago

> What can’t it do. Async I/O.

ejb999 4y ago

>>Over the last 15 or 20 years I’ve tried lots of databases of all flavors and every time come back to Postgres. Almost the same here, have tried just about everything that comes along, and sooner or later I end up swapping out the database de jour and go right back to sql server in almost all use cases (for the type of projects I do). I feel like db's are pretty much a solved problem, and can't imagine trying to build and market a brand new one these days. Almost as hard as trying to come up with a new operating system and convincing people to switch. I wish good luck to anyone that tries, but talk about pushing a boulder up a mountain; definitely doesn't seem like the easy path to success.