Re: Database Scalability

From: SQL Padawan <sql_padawan(at)protonmail(dot)com>
To: Ben Chobot <bench(at)silentmedia(dot)com>
Cc: Mladen Gogala <gogala(dot)mladen(at)gmail(dot)com>, pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: Database Scalability
Date: 2021-12-01 18:22:40
Message-ID: _t8HMEZ0d_67otynMLlQsUo0UzyaOgqzPUWfcwTzb0MZbqZqt1DzHb8FfYj8AN5bOBQKi0LzroP81AlT3V2qniuJuxQrdtg9w_SyBH1y_6w=@protonmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

> > To my knowledge PostgreSQL doesn't support sharding, which is well and
> >
> > good because sharding is mostly useless, at least in my opinion.

> Not only does PostgreSQL natively support table partitioning (which is
>
> absolutely a form of sharding), there multiple well-regarded extensions
>
> that can help with sharding, all of which are orthogonal to how you can
>
> configure your application to use Postgres in the first place. So to say
>
> Postgres doesn't support sharding is.... misleading, at best.
>
> Also, the general concept of sharding to move your scaling challenges
>
> from vertical ones to horizontal ones has multiple self-evident
>
> advantages. If your work history has all happened to fit on a single
>
> server, then bully for you, but not everybody has it so easy.

It supports partitioning out of the box - not sharding where different tables reside on different machines!

CitusData and TimescaleDB provide sharding as extensions - both of which appear useful for TimeSeries data. There was PostgresXL which was a general sharding (multi-machine) solution that appears to have died.

SQLP!

In response to

Browse pgsql-general by date

  From Date Subject
Next Message SQL Padawan 2021-12-01 18:37:37 Pgcrypto extension - decrypt(encrypt(... not returning original data?
Previous Message Tom Lane 2021-12-01 16:10:28 Re: Linux: directory change .../lib to .../lib64