Re: Database Scalability - Mailing list pgsql-general

From SQL Padawan
Subject Re: Database Scalability
Date
Msg-id _t8HMEZ0d_67otynMLlQsUo0UzyaOgqzPUWfcwTzb0MZbqZqt1DzHb8FfYj8AN5bOBQKi0LzroP81AlT3V2qniuJuxQrdtg9w_SyBH1y_6w=@protonmail.com
Whole thread Raw
In response to Re: Database Scalability  (Ben Chobot <bench@silentmedia.com>)
List 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
PostgresXLwhich was a general sharding (multi-machine) solution that appears to have died. 

SQLP!





pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: Linux: directory change .../lib to .../lib64
Next
From: SQL Padawan
Date:
Subject: Pgcrypto extension - decrypt(encrypt(... not returning original data?